babel-loader: `resolveLoader.root` not being taken into account?

Would also like to see a proper fix for this. Using require.resolve seems to be workaround:

    query: {
      presets: [
        require.resolve('babel-preset-es2015'),
        require.resolve('babel-preset-react'),
        require.resolve('babel-preset-stage-0'),
      ],
    },

@globexdesigns Instead of using require.resolve for each entry, I did this: (not JSON; I’m using the Babel require hook)

plugins: [
    "babel-plugin-add-module-exports",
    "babel-plugin-transform-decorators-legacy"
].map(require.resolve),
presets: [
    "babel-preset-es2015",
    "babel-preset-stage-0",
    "babel-preset-react"
].map(require.resolve)

Especially useful if you have a bunch of entries.

If you want, you can add babel-{preset, plugin} with the map function, allowing you to use an unmodified plugin/preset stanza (but I prefer using the npm name).

FYI: The resolve hack for this is also needed for plugins as well:

plugins: [
    require.resolve("babel-plugin-add-module-exports"),
    require.resolve("babel-plugin-transform-decorators-legacy")
],
presets: [
    require.resolve("babel-preset-es2015"),
    require.resolve("babel-preset-stage-0"),
    require.resolve("babel-preset-react")
]

To support passing preset / plugin configuration along with declarations, I’ve created a tiny function that I call localResolve:

function localResolve(preset) {
    return Array.isArray(preset) ?
           [require.resolve(preset[0]), preset[1]] :
           require.resolve(preset);
}

which I then use like this:

{
    test: /\.js?$/,
    loader: "babel-loader",
    exclude: /node_modules/,
        query: {
            presets: [
                ["babel-preset-env", {
                    modules: false,
                    "targets": {
                        "browsers": ["last 2 versions"]
                    },
                }],
                "babel-preset-stage-3",
            ].map(localResolve),

            "plugins": [
                "babel-plugin-transform-runtime"
            ].map(localResolve),
        },
    },
}

Btw you can also pass plugins/presets arrays filled with references, not the strings. You require needed stuff first:

    const babelPresets = [
        require('babel-preset-es2015')
    ];
    const babelPlugins = [
        require('babel-plugin-transform-class-properties')
    ];

And then you connect that to the webpack’s config with babel property name:

        babel: {
            presets: babelPresets,
            plugins: babelPlugins,
            cacheDirectory: true
        }

In this case obviously babel doesn’t resolve plugins/presets locations by string names, but uses passed by the reference instances. But it’s not a very flexible way since it’s a global config, not the per loader config. Passing instantiated plugins/presets references to the loader’s query property doesn’t work since webpack converts references to strings.

I did a brief issue debugging and so far for me it looks like that it’s not in babel-loader power to make resolveLoader.root webpack’s property work for babel since babel resolves plugins/presets modules locations based on the processed file and babel has no explicit option like modules root directory.

resolveLoader only affects modules referenced within the code being bundled, not things loaded by the loaders themselves, like babel-loader’s plugins.

babel-loader resolves all of it’s arguments relative to the current working directory, so you should either explicitly require plugins/presets that you want to use, or consider setting cwd to the conceptual root of your project. Which of these you do kind of depends on why your dependencies aren’t already resolvable.

Note: This working-directory-relative behavior is new in Babel 7. Babel 6 resolved things relative to each individual file, which was definitely terrible, so hopefully that reduces the need to handle this stuff manually anyway.

Almost 2018 - Has this been addressed ? Or require.resolve is still in play ?

Update: Seems that creating a symlink pointing to the node_modules is also a viable workaround.

👍 I am running into this as well.

Having the same issue when using symlinks…