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
Allow globs for manualChunks #2336
Comments
A filtering function would be nice too, so any possible kind of filtering could happen. manualChunks : {
vendor : (id) => id.includes("node_modules/")
} |
This is not possible as glob behaviours are not defined in the module resolver, therefore there is no way to make this a well-defined feature without it having edge cases causing bugs. Also note that you are free to write code in Rollup configurations that can handle this. |
Would this be globbing the target directory within the rollup config, and then setting something like this: manualChunks : {
vendor : [ /* all files matched by glob */ ]
} ? |
@tivac yes exactly. So filtering is a nice concept, but currently manualChunks allow defining new entry points. That is, if I set We could consider reworking manualChunks to be simply a filtering. That is we run the build on the entry points, working out graph etc. Then we run through the modules included, and pull into a manual chunk anything from there. The difference though would be that defining The difference between the two cases being, in the one we have the ids to run a filter on, and in the other, we have only the name before resolution, so globbing makes less sense in that id space. |
Also it's quite nice to entirely use the |
I think the fundamental issue for me was that I thought I'm sure there's a use-case for it working that way, but it's definitely not what I expected given any of the documented examples of It also means that the glob suggestion up above would probably make for insanely slow builds, since rollup would have to tree-shake literally everything within the |
@tivac yes exactly :) I'd have thought manual chunks being defining of chunks rather than filtering was more common-sense.... but I'm totally open to changing this if you think it would be better as simply a filter. Then yes we can minimatch and glob away certainly. Perhaps it would just need a docs note. (although the next thing is then it might be confusing why only manualChunks gets this support...!) |
A docs note explaining what |
@tivac not faulty - maybe a better viewpoint. I'm wondering if we should change manual chunks to work as a filter like you suggest. What do you think? |
I think it'd be more intuitive and useful, but would be interested in hearing from folks who actually use it as it works today. |
I've no objection to the existing function remaining as is [and perhaps the docs clarifying what its purpose is]... but I'd also like a way to control which bundle any package is output into. Perhaps I've just never got my head around how the existing machinery should be used for such purposes. I find too much of the docs seem to be written for people who already understand all the concepts and terms. |
I implemented #2831 which will not allow you to use globs but allows you to define |
Currently manualChunks requires you to explicitly name each module you want in a chunk.
For my case, I would find it much more useful to be able to specify globs, instead, so I could, for instance, use:
to place all 3rd party packages in a vendor chunk.
The text was updated successfully, but these errors were encountered: