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

[Feature]: Init command's splitChunks caching group generation per provided entry #404

Closed
EugeneHlushko opened this issue Apr 14, 2018 · 13 comments · Fixed by #2310
Closed

Comments

@EugeneHlushko
Copy link
Member

EugeneHlushko commented Apr 14, 2018

Do you want to request a feature or report a bug?

feature

What is the current behavior?
it doesnt output caching group per entry provided

If the current behavior is a bug, please provide the steps to reproduce.
after #356 is merged
use webpack-cli init and provide multiple entries
Observe splitChunks plugin declaration doesnt add caching group per entry

What is the expected behavior?
splitChunks caching groups added per entry

If this is a feature request, what is motivation or use case for changing the behavior?
TBD @ev1stensberg

Please paste the results of webpack-cli info here, and mention other relevant information such as programming language.

NOTE
When trying to initally set up regexp generation i bumped into a case where user might provide two entries from within same directory when doing simple config generations e.g. for entries user types:
homepage,blog

and for entry paths:

./src/homepage
./src/blog

In this case regexp for catching files in splitChunks will be the same for both entries if entries are

./src/homepage.js
./src/blog.js

and not directories with a nested index.js file.

./src/homepage/index.js
./src/blog/index.js
@ematipico
Copy link
Contributor

ematipico commented Apr 15, 2018

We're ready to proceed with this one now

@bitpshr
Copy link
Member

bitpshr commented Apr 27, 2018

Is this still a relevant feature? If so, I'd be happy to take it on now with a bit of clarification. Is the intention to define a cacheGroups entry for each configured entry point? Should this behavior be opt-in, or should it be the default when initializing a new project?

@evenstensberg
Copy link
Member

evenstensberg commented Apr 28, 2018

yes, @EugeneHlushko could you elaborate some more? 📦 It should be default when initializing a new project with multiple entries, yes.

@bitpshr
Copy link
Member

bitpshr commented Apr 30, 2018

Thanks for the info, I'll pick this up. Feel free to assign it to me to keep it on my radar.

@EugeneHlushko
Copy link
Member Author

Yeah its pretty much relevant. As @ev1stensberg we think that it should be default for multiple entries. The catch here is described in the issue description, if entries are .js files in one dir, everything will fall under the same caching group, needs a thought.

@evenstensberg evenstensberg changed the title Init command's splitChunks caching group generation per provided entry Feature: Init command's splitChunks caching group generation per provided entry May 18, 2018
@evenstensberg
Copy link
Member

@dhruvdutt maybe you could pick this one up?

@dhruvdutt dhruvdutt self-assigned this Sep 4, 2018
@dhruvdutt
Copy link
Member

Sure! Would try to finish over the weekend.

@webpack-bot
Copy link

This issue had no activity for at least half a year.

It's subject to automatic issue closing if there is no activity in the next 15 days.

@evenstensberg evenstensberg reopened this Mar 31, 2019
@ematipico ematipico removed the v3 label Apr 3, 2019
@evenstensberg evenstensberg removed this from the Vatican (v3) milestone Apr 8, 2019
@evenstensberg evenstensberg changed the title Feature: Init command's splitChunks caching group generation per provided entry [Feature]: Init command's splitChunks caching group generation per provided entry Oct 31, 2019
@webpack-bot
Copy link

This issue had no activity for at least half a year.

It's subject to automatic issue closing if there is no activity in the next 15 days.

@alexander-akait
Copy link
Member

bump

@bitpshr
Copy link
Member

bitpshr commented Apr 30, 2020

Circling back on this; @evenstensberg and @ematipico, is this still relevant? I have bandwidth to take this on now if so.

@dhruvdutt dhruvdutt removed their assignment Jun 21, 2020
@webpack-bot
Copy link

This issue had no activity for at least half a year.

It's subject to automatic issue closing if there is no activity in the next 15 days.

@webpack-bot
Copy link

Issue was closed because of inactivity.

If you think this is still a valid issue, please file a new issue with additional information.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants