feat(lib): allow multiple entries

[schummar]

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]

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

[Niputi]

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

[schummar]

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]

yup. should be mentioned in docs

[schummar]

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

[Tumulte]

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

[schummar]

@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]

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

[bluwy]

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]

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

[pd4d10]

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]

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]

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]

@schummar Need this feature +1. Any update?

[kasvith]

Any updates?

[schummar]

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

[patak-dev]

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]

Thanks, this is a really valuable feature for vite

[mrcego]

+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]

💯 After #7275, this would fix #9086

[boogiefromzk]

+1 from me.

[philcockfield]

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! 🍰

[schummar]

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]

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]

@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]

@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]

@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]

Is this landing any time soon? 🥺

[SteveDesmond-ca]

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

[schummar]

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]

@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]

@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?

[Juice10]

@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]

@Juice10 PR is open now: #10609