You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would be helpful if I could allow to specify the AMD loader config by pointing to a file[1] which contains require.config call itself, not only via inline loaderOptions. This is how, for example, RequireJS optimizer allows to specify the config.
[1] In fact, I would like to be able to specify list of files - I've got config.js for production and config-test.js with additional pieces of AMD config in a seperate config file. For now, I must use the ugly workaround, having this in separate file config-all-options.js:
// Take config.js and config-test.js from root and extract// just the options passed to require.config, merged.define(['../../bower_components/lodash-compat/lodash','intern/dojo/text!config.js','intern/dojo/text!config-test.js'],function(_,configJs,testConfigJs){varoptions={};(function(require){eval(configJs);eval(testConfigJs);})({config: function(x){options=_.merge(options,x);}});returnoptions;});``` and define intern config as:```jsdefine(['./support/config-all-options'],function(options){return{/// ...loaderOptions: options,/// ...}});
The text was updated successfully, but these errors were encountered:
Personally, I've always hated how the RequireJS optimizer scans a file for a require.config() call and parses its argument. It feels very hacky to me. And that whole paradigm is poisonous, since it leads to feature requests like this across many projects.
What I do is define all of my AMD configuration in a real module that can be read by any tooling that can consume that module. Then, during my build process, any nonsense like require.config() is simply constructed and written to disk wherever it is needed. This setup is more flexible, maintainable, and declarative. Because this has treated me well, my vote is to avoid parsing like this.
Basically, I'm suggesting to think from the other direction and treat require.config() as a special case, where your config needs to be serialized for the client. Once you get into that mindset, you regain all of the usual benefits of real modules, which the RequireJS optimizer really should not have stolen from you in the first place.
Intern's configuration system is quite different now, and an external loader is no longer required when running on Node (assuming your code and suites are CommonJS). You can use multiple config files, or multiple config profiles in a single config file, to hold different loader configs. You could also load a config module as a plugin.
It would be helpful if I could allow to specify the AMD loader config by pointing to a file[1] which contains
require.config
call itself, not only via inlineloaderOptions
. This is how, for example, RequireJS optimizer allows to specify the config.[1] In fact, I would like to be able to specify list of files - I've got config.js for production and config-test.js with additional pieces of AMD config in a seperate config file. For now, I must use the ugly workaround, having this in separate file
config-all-options.js
:The text was updated successfully, but these errors were encountered: