Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(lib): allow multiple entries #7047

Merged
merged 1 commit into from
Sep 30, 2022

Conversation

schummar
Copy link
Contributor

Description

Hi, I think it's a common occurrence that libraries provide multiple entrypoints, so it would be nice if Vite's library mode supported this scenario. Since rollup does the heavy lifting, the main challenge is to provide a nice and simple interface.

The idea would be for entry to have rollup's InputOption interface and to tweak fileName and the resulting file names and chunk names accordingly. All without chaning the behavior for existing cases of course.

Example:

lib: {
  entry: {
      primary: 'src/index.ts',
      secondary: 'src/secondary.ts'
  },
  formats: ['es', 'cjs']
}
// => primary.es.js, primary.cjs.js, secondary.es.js, secondary.cjs.js

or

lib: {
  entry: ['src/index.ts', 'src/secondary.ts'],
  formats: ['es', 'cjs']
}
// => index.es.js, index.cjs.js, secondary.es.js, secondary.cjs.js

Additional context

There is an issue regarding the topic, though the proposed interface differs: #4530
Some discussion has been going on here: #1736


What is the purpose of this pull request?

  • Bug fix
  • New Feature
  • Documentation update
  • Other

Before submitting the PR, please make sure you do the following

  • Read the Contributing Guidelines.
  • Read the Pull Request Guidelines and follow the Commit Convention.
  • Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
  • Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123).
  • Ideally, include relevant tests that fail without this PR but pass with it.

@Niputi Niputi changed the title feat: allow multiple entries for lib mode feat(lib): allow multiple entries Feb 22, 2022
@Niputi Niputi added the p2-nice-to-have Not breaking anything but nice to have (priority) label Feb 22, 2022
@Niputi
Copy link
Contributor

Niputi commented Feb 22, 2022

for this the entry points would need to be added to the package json exports

@Niputi
Copy link
Contributor

Niputi commented Feb 22, 2022

after #6827 file names will be a bit different to give correct file names

@schummar
Copy link
Contributor Author

for this the entry points would need to be added to the package json exports

Indeed. But this is not Vite's concern, right? It should probably be mentioned in the docs under "Recommended package.json for your lib".

@Niputi
Copy link
Contributor

Niputi commented Feb 23, 2022

yup. should be mentioned in docs

@schummar
Copy link
Contributor Author

I have added some docs and another check. Is there anything obvious missing?

@Tumulte
Copy link

Tumulte commented Mar 5, 2022

I very much look forward for this to be merged. to reply, I think the array option can benefit from a little bit more highlight than just a comment... but it’s a much needed feature and thank you

@bluwy bluwy added p2-to-be-discussed Enhancement under consideration (priority) and removed p2-nice-to-have Not breaking anything but nice to have (priority) labels Mar 6, 2022
@bluwy bluwy linked an issue Mar 6, 2022 that may be closed by this pull request
4 tasks
@schummar
Copy link
Contributor Author

schummar commented Mar 9, 2022

@bluwy I see that the to-be-discussed label has been added. How does that work? I'm happy to discuss any open questions.

@Niputi
Copy link
Contributor

Niputi commented Mar 9, 2022

it will be discussed at a team about the approach and if it should go in

@bluwy
Copy link
Member

bluwy commented Mar 9, 2022

That means we will be discussing about this in the next team meeting (if we have the time) 😄 I'd like to review this PR myself too, but we'll have to see if the new API is good to go.

@schummar
Copy link
Contributor Author

schummar commented Mar 9, 2022

Alright, let me know if I can contribute/clarify/justify something or if you require changes. Thanks!

@pd4d10
Copy link
Contributor

pd4d10 commented Apr 3, 2022

Need this feature +1. Any update?

The solution proposed in #4530 seems to be more flexible, with the possibility of specifying different formats and UMD names for different lib entries

@schummar
Copy link
Contributor Author

The solution proposed in #4530 seems to be more flexible, with the possibility of specifying different formats and UMD names for different lib entries

True, it's a bit more flexible. However it's also more complex to implement and has other limitations. Also, if you're aiming for maximum flexibility I would argue it doesn't go far enough. What it you want to configure e.g. different rollupOptions, sourcemaps etc. for different entrypoints? Then maybe passing an array of configs at the top level makes the most sense.

I think we are not talking about mutually exclusive features here, both havbe their advantages:

  • This PR:
    + Lightweight: mostly passing the config along to rollup
    + Should be enogh for most cases: Most libs export multiple entrypoints with the same formats/settings, I assume
    + Does code splitting builds. That means that shared code between entry points is move to separate chunks and not duplicated
    - Does not cover all uses cases
    - Rollup does not support code splitting builds for UMD: Consider UMD / IIFE support for code splitting rollup/rollup#2072

  • Multiple configs on lib or root level:
    + Very flexible
    - Boilerplate: Probably one will have to repeat a lot of options
    - No shared chunks between entrypoints

@schummar
Copy link
Contributor Author

Possibly the UMD (and IIFE) case should be covered better in this PR as well. Currently you would see an error when trying to have multiple entrypoints and one of the formats is UMD. I think good behavior would be: For other formats, just feed it into rollup as is currently done. For UMD and IIFE, extra builds could be triggered per entrypoint.

I'd be happy to build it, but before putting more effort in it I would wait for the team's feedback, if the api makes sense for them at all.

@palmerye
Copy link

@schummar Need this feature +1. Any update?

@kasvith
Copy link

kasvith commented Jun 14, 2022

Any updates?

@schummar
Copy link
Contributor Author

Haven't heard anything for quite some time. @Niputi @bluwy?

@patak-dev
Copy link
Member

We had a big backlog while we are working to release v3, so we haven't had time yet to review this one in a team meeting. We'll comment once we do.

@kasvith
Copy link

kasvith commented Jun 14, 2022

Thanks, this is a really valuable feature for vite

@mrcego
Copy link
Member

mrcego commented Jul 10, 2022

+1 for the head up. It's a titanic work making adequately a multientry build in lib mode, at least with Web Components libs.

@SteveDesmond-ca
Copy link

💯 After #7275, this would fix #9086

@boogiefromzk
Copy link

+1 from me.

@philcockfield
Copy link

Another +1 over here.
Just knowing this will land at some point (hopefully soon) changes radically architecture decisions and approach to multi-module/project layout. Thanks everyone for getting this PR in! 🍰

@patak-dev patak-dev added p3-significant High priority enhancement (priority) and removed p2-to-be-discussed Enhancement under consideration (priority) labels Aug 15, 2022
@schummar
Copy link
Contributor Author

I have rebased the changes onto current main now. Still awaiting the team's feedback, but the p3-significant label is probably a good sign 😁

@schummar
Copy link
Contributor Author

schummar commented Aug 16, 2022

Outline for possible multi entries support for umd and iife:
schummar@22fda78

Needs fine tuning obviously, but works in principle. With the expected downside of course, that no code splitting takes place and redundant code is put into files. E.g.:

vite v3.0.8 building for production...
✓ 2 modules transformed.
dist/myLib.mjs            1.04 KiB / gzip: 0.58 KiB
dist/myLibSecondary.mjs   1.07 KiB / gzip: 0.62 KiB // Imports myLib
✓ 3 modules transformed.
dist/myLib.umd.js   1.22 KiB / gzip: 0.72 KiB
✓ 5 modules transformed.
dist/myLibSecondary.umd.js   2.23 KiB / gzip: 0.74 KiB // Duplicates content of myLib

@drewloomer
Copy link

@schummar this is great! I tried running it locally and get a Multiple entry points are not supported when output formats include "umd" or "iife". error. Any thoughts on how we might get around that?

@schummar
Copy link
Contributor Author

@drewloomer that's a limitation of Rollup (see rollup/rollup#2072), which we might be able to work around.

I have described a possible solution before (#7047 (comment), #7047 (comment)) but it will create redundant output, which might or might not be a deal breaker. If you want you can try it out from this branch: https://github.com/schummar/vite/tree/feature/libMultiEntryUMD

@schummar
Copy link
Contributor Author

@drewloomer it just occurred to me that the confusion could also come from "es" and "umd" being the default output format, which will then just show an error. That is unfortunate indeed. Maybe one way to solve it could be, to change the default format when using multiple entry points...

For now the best way to configure it, is to use formats: ['es', 'cjs'], if you don't specifically need umd output.

@hmendes00
Copy link

Is this landing any time soon? 🥺

@SteveDesmond-ca
Copy link

Would #10116 (once it gets merged) make this PR redundant? Or are they doing slightly different things?

@schummar
Copy link
Contributor Author

Would #10116 (once it gets merged) make this PR redundant? Or are they doing slightly different things?

I'd say they are not quite the same. By overriding rollupOptions.input, you can reach mostly the same goal (but not for the UMD/IIFE case!), but allowing to do so with lib.entries is the the cleaner, more intuitive way. In my opinion, fiddling with rollupOptions should be for more advanced, more out-of-the-ordinary use cases. Having multiple entrypoints however is very common and should not require "hacking".

@patak-dev patak-dev added this to the 3.2 milestone Sep 23, 2022
@patak-dev
Copy link
Member

@schummar thanks for your patience on this PR, we discussed it in the last team meeting and got a consensus on moving forward with it. And we think your proposed API is the right way to go. We are starting to work towards 3.2 and we can include this feature in it. Would you resolve the conflicts when you have a chance?

@schummar
Copy link
Contributor Author

@patak-dev cool! I have rebased the branch and the conflict is gone. One test is failing but it's failing on main as well, so I guess nothing to do for me.

I suggest finishing this PR with the scope it has now - including whatever changes you still require. After merging I would then open new PRs for the other suggestions (different default formats when using multiple entries, non-code splitting build for UMD and IIFE with multiple entries). Ok?

@patak-dev patak-dev merged commit 65a0fad into vitejs:main Sep 30, 2022
@schummar schummar deleted the feature/libMultiEntry branch October 2, 2022 19:20
@Juice10
Copy link

Juice10 commented Oct 23, 2022

@schummar

@drewloomer that's a limitation of Rollup (see rollup/rollup#2072), which we might be able to work around.

I have described a possible solution before (#7047 (comment), #7047 (comment)) but it will create redundant output, which might or might not be a deal breaker. If you want you can try it out from this branch: https://github.com/schummar/vite/tree/feature/libMultiEntryUMD

Un-chunked umd versions would be super useful for us at https://github.com/rrweb-io/rrweb. Because we end up injecting all the code in a browser via puppeteer un-chuncked is actually preferred as it makes it a lot less complex to inject one file vs many.
Would it be possible to create a PR for the feature/libMultiEntryUMD branch you created?

@schummar
Copy link
Contributor Author

@Juice10 PR is open now: #10609

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feat: library mode p3-significant High priority enhancement (priority)
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

Please support multiple entry points for library mode