webpack
Concerns about configuration database
I'm not sure if a centralized database would be a good thing. I fear that this database would always be one step behind. When a module comes with a "new" module type (meaning that it is not handled by the database yet) that leads again to the situation that the module author needs to add a README for the application author explaining how to handle that unknown module type in the application config.
Instead of using a database, I suggest letting the module itself define the defaults.
The module author knows best how the module should be used/treated optimally, so why not define the defaults there?
The "dependencies" could be simple devDependencies in the package.json.
Further, any consuming (depending) module may override that configuration and could itself be overriden, if necessary. The application itself to me is just like any other module.
Assume the following dependency tree as an example:
APP
|
|
+----------*-----------+
| |
| |
module A module B
|
|
+---------------*---------------+
| | |
| | |
module C module D module E
|
|
module F
Modules F, D, and E must define a complete module type configuration for those types that they come with. The parent modules like module C, A or APP can override parts of the configuration.
Modules F and D may have different (contradicting) configurations that shall be respected individually for those assets that they bring themselves. For example, module F may come with SVG files that must remain as-is (because the module needs access to the SVG DOM), while module D just uses them as graphics and doesn't care should they be converted to a raster file. Still, for both modules the files may be inlined or remain external.
I fear that there are simply too many specific situations to handle, so that it would be would be near impossible as to have a complete database that has an answer to each combination.
Another problem with it is, that IMHO the application developer should be forced to think about and decide some fundamental configuration decisions, like ECMAScript language level, browser support etc.
This configuration "database" is different for each bundler, so this can't be described in a module (which should be independent from the buildsystem). But if every bundler would use a GitHub repository published as npm module, new file types could be added easily.
Modules F and D may have different (contradicting) configurations that shall be respected individually for those assets that they bring themselves. For example, module F may come with SVG files that must remain as-is (because the module needs access to the SVG DOM), while module D just uses them as graphics and doesn't care should they be converted to a raster file. Still, for both modules the files may be inlined or remain external.
In this case the file type of the SVG should be different (e.g dom/svg and image/svg), so contradicting configurations would be no problem.
Another problem with it is, that IMHO the application developer should be forced to think about and decide some fundamental configuration decisions, like ECMAScript language level, browser support etc.
That's true. Also performance improvements like in-lining stuff shouldn't be decided on module, but on application level.
But if every bundler would use a GitHub repository published as npm module, new file types could be added easily.
For file types to make sense, all bundlers would need to agree on a identical set of known file types (only the implementation may change). It would be useless to have a file type "dom/svg" that is handled differently depending on the bundler.
How do you think to handle that - and who?
How do you think to handle that - and who?
I plan a repo which contains exact specs for each module type (splitted by content type, export type and modification type). The API and behavior must be specified. Everyone can add types by PR and they can be used before merged via type+rfc123 (123 is PR number). Once the community agree on the best spec for this type, it'll be merged and is available as type. The old types can still be used with type+rfc123.
For adding features to existing types you can do the same with PRs.
Another problem with it is, that IMHO the application developer should be forced to think about and decide some fundamental configuration decisions, like ECMAScript language level, browser support etc.
That's true. If you take a look at the example module types there is an idea to handle this. The module author tells with ecmascript level is used via features (i. e. javascript+es5). On application level you can handle this i. e. by transforming or polyfilling. How it's handled is out of scope for this spec. Modules just provide this information.
That sounds like a good idea to me. It's at least a way to tackle the current module anarchy ^^