There are a few issues with #69 and the 5.0 release. The babel config uses relative preset/plugin names like "env", which causes babel to resolve it relative to the project's directory, not the directory where extract-loader is installed. If the user's project does not use Babel 6, or uses a different version, that is a problem.
The fix for that is to do require('babel-preset-env') in the babel config, so it resolves to the version of that package installed with extract-loader.
I tried to fix that but ran into a different issue. babel-preset-env is not listed as a dependency, but as a devDependency for extract-loader. That is an easy fix of course, but I'm not sure if it's the best thing to do to depend on babel-preset-env. If the goal is only to support ES modules, would it be a better idea to use babel-plugin-modules-commonjs?
There are a few issues with #69 and the 5.0 release. The babel config uses relative preset/plugin names like
"env"
, which causes babel to resolve it relative to the project's directory, not the directory where extract-loader is installed. If the user's project does not use Babel 6, or uses a different version, that is a problem.The fix for that is to do
require('babel-preset-env')
in the babel config, so it resolves to the version of that package installed with extract-loader.I tried to fix that but ran into a different issue. babel-preset-env is not listed as a dependency, but as a devDependency for extract-loader. That is an easy fix of course, but I'm not sure if it's the best thing to do to depend on babel-preset-env. If the goal is only to support ES modules, would it be a better idea to use
babel-plugin-modules-commonjs
?