Many packages on npm these days (notably "d3-*") aren't pre-transpiled to iron out stable language features that don't work in IE11 (which we sadly still need to support), and even some newer features that not all modern browsers support. We've gotten around this in the past by hacking into the webpack config in aunty.config.js, so that babel processes those dependencies too:
const { resolve } = require('path');
module.exports = {
webpack: config => {
const rules = config.module.rules;
const scriptsRule = rules.find(x => x.__hint__ === 'scripts');
scriptsRule.include.push(resolve(__dirname, 'node_modules/aframe')); // Exact path to dependency
scriptsRule.include.push(/node_modules\/d3-/); // Path regex: will match all "d3-*" dependencies under node_modules
return config;
}
};
I propose we let aunty do all of this under the hood by feeding it a list of strings and/or RegExp objects to define external dependencies we want to transpile on the build config prop. Here's how we'd define this:
module.exports = {
build: {
includedDependencies: [
'aframe', // strings will be auto-resolved relative to the project's node_modules directory
/d3-/ // regular expressions will have "node_modules/" prefixed to them
]
}
};
Many packages on npm these days (notably "d3-*") aren't pre-transpiled to iron out stable language features that don't work in IE11 (which we sadly still need to support), and even some newer features that not all modern browsers support. We've gotten around this in the past by hacking into the webpack config in aunty.config.js, so that babel processes those dependencies too:
I propose we let aunty do all of this under the hood by feeding it a list of strings and/or RegExp objects to define external dependencies we want to transpile on the build config prop. Here's how we'd define this:
Thoughts? (including the build prop name)