At Symfony Live, @trappar had an interesting idea: a way to automatically add entries based off of a glob pattern. For example, perhaps all .js files in the root of assets/ should be entry files (assets/*.js). Then it would be cool to be able to say:
Encore.addEntries('assets/*.js')
The one problem is that when you add new files, it would mean that your webpack.config.js config will need to change (we would need to add the new entry). That's a problem because you'll need to restart encore if you're using --watch. So... that's a bit of a "gotcha" with this feature. We could manually "watch" this directory for new files in Encore and add a notification (#187) in this situation.
@weaverryan Some questions about that:
@Lyrkan
What would be the name of the generated entries in this case?
In the project where I'm doing this I use something like the following to convert a glob path/pattern into an entry object:
const path = require('path');
const glob = require('glob');​
const globToEntry = (base, pattern) => {
return glob.sync(path.join(base, pattern)).reduce((entry, file) => {
const parsedPath = path.parse(path.relative(base, file));
entry[path.join(parsedPath.dir, parsedPath.name)] = path.resolve(file);
return entry;
}, {});
};
I like this because it maintains the same folder structure inside my assets folder when the public versions are built, which allows me to use something like: globToEntry('assets', '**/*.js') to turn assets/admin/users.js into public/build/admin/users.js
Wouldn't that encourage bad practices?
I personally don't see having many entry points as a bad practice. Any significantly large MPA is going to end up having tons of them, and that isn't a terribly inefficient way of building an app as long as common chunks and code splitting are being used properly. Sure moving toward SPA architecture might be more ideal for many applications using Webpack, but that doesn't mean that this package shouldn't support other styles of application as well. Just my opinion.
Hi @trappar,
Don't get me wrong, I'm not saying that this is an issue to do that if you know what you are doing (i.e. being able to set it up correctly in order to have good common chunks, using JS modules correctly, etc.).
What I'm worried about is that newcomers may abuse that method by ignoring the usual addEntry and adding all of their JS files as entry points.
@Lyrkan Maybe once we have the init generator stuff... this could be less of a worry. I mean, if we generate a really, clear, consistent structure (where it's really clear where you entry points go, and where other JS goes... and if we also have a add:entry generator command, it adds files to this directory), then this glob idea becomes less dangerous.
I'm not sure if it will be abused or not, but I hear what you're saying and it's at the very least, a valid thing to think about.
Closing this, at least for now. Not sure it's a good idea, and there are complications
Most helpful comment
@Lyrkan
In the project where I'm doing this I use something like the following to convert a glob path/pattern into an entry object:
I like this because it maintains the same folder structure inside my assets folder when the public versions are built, which allows me to use something like:
globToEntry('assets', '**/*.js')to turnassets/admin/users.jsintopublic/build/admin/users.jsI personally don't see having many entry points as a bad practice. Any significantly large MPA is going to end up having tons of them, and that isn't a terribly inefficient way of building an app as long as common chunks and code splitting are being used properly. Sure moving toward SPA architecture might be more ideal for many applications using Webpack, but that doesn't mean that this package shouldn't support other styles of application as well. Just my opinion.