Webpack-encore: Automatic entries via a glob pattern

Created on 20 Oct 2017  Â·  5Comments  Â·  Source: symfony/webpack-encore

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.

feature

Most helpful comment

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

All 5 comments

@weaverryan Some questions about that:

  • What would be the name of the generated entries in this case?
  • Wouldn't that encourage bad practices? (having so many entry points that it becomes inconvenient to add them one by one)

@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

Was this page helpful?
0 / 5 - 0 ratings