[Feature] Custom Loader Config Generators
See original GitHub issueI’m submitting a feature request It would be nice to have the ability to create our own loader config generator so that custom configs for the application (whether it’s RequireJS, SystemJS, or any other module loader) can be created. This would allow a user to generate their own config for their own setup without having to rely on the CLI to provide one itself.
Additionally, having the ability to create you own loader config comes with the benefits of creating custom configs that are needed for testing frameworks like Karma and Wallaby.
What we could do is provide the basic configuration setups (currently just RequireJS, and hopefully soon SystemJS and Webpack), but allow the user to define their own in the aurelia.json
file. I’m thinking that we could make use of the build.loader.type
option to do this. The CLI could look at the type and if it matches one of the prebuilt ones (require, system, webpack) then it would simply use the one it had. But if it didn’t match a prebuilt generator, then we could read it as a path to load the custom generator.
For example. A default configuration looks like this for the loader:
"loader": {
"type": "require",
"configTarget": "vendor-bundle.js",
"includeBundleMetadataInConfig": "auto",
"plugins": [
{
"name": "text",
"extensions": [
".html",
".css"
],
"stub": true
}
]
},
Using that setup, we would simply use the prebuilt requirejs config generator. But the user could also do something like this:
"loader": {
"type": "configGenerators/awesome-loader",
"configTarget": "vendor-bundle.js",
"includeBundleMetadataInConfig": "auto",
"plugins": [
{
"name": "text",
"extensions": [
".html",
".css"
],
"stub": true
}
]
},
This setup would not match any prebuilt generator, and instead would now look to the file path listed to load up the generator and create the module loader configuration.
Thoughts, ideas?
The immediate use we would have for this would be to create custom configurations for Karma and Wallaby test runners.
Issue Analytics
- State:
- Created 7 years ago
- Reactions:1
- Comments:6 (6 by maintainers)
I’m not sure this is even a highly needed feature anymore. At the time of the original feature request, our department was in the midst of a transition of builders, and we had some weird quirks we were trying to work around. I think at this point there’s enough functionality that solves the original problem we had. Since there hasn’t been any activity on this, I think it’s worth closing down. If somebody ends up wanting this, we can resurrect this thread, or more likely open a new one and reference this one.
I think it’s already implemented.