Posted in Uncategorized

Breaking change introduced between 2.2.1 and 2.3.0 – relative/absolute paths

   February 23, 2021  5 Comments on Breaking change introduced between 2.2.1 and 2.3.0 – relative/absolute paths

Do you want to request a feature or report a bug?

What is the current behavior?

The current NPM semantic version standards state that changes between minor versions should be non-breaking.

https://docs.npmjs.com/getting-started/semantic-versioning

However the treatment of configuration between 2.2.1 and 2.3.1 has introduced a breaking change.

Invalid configuration object. Webpack has been initialised using a configuration object that does not match the API schema.
 - configuration.output.path: The provided value "./ui/app" is not an absolute path!

I guess this is done now and I doubt you’ll want to fix it, but I thought you should know, as you use NPM for distribution, that you’re not applying their versioning standards, which are required for the correct use of version specification in package.json. ie. ^2.2.1 will currently resolve to 2.3.1

If the current behavior is a bug, please provide the steps to reproduce.

  • Using webpack 2.2.1 configure a relative output path
  • Upgrade to webpack 2.3.1 and observe the failure

What is the expected behavior?

Minor version changes should not introduce breaking changes

If this is a feature request, what is motivation or use case for changing the behavior?

Please mention other relevant information such as the browser version, Node.js version, webpack version and Operating System.

Author: Fantashit

5 thoughts on “Breaking change introduced between 2.2.1 and 2.3.0 – relative/absolute paths”

  1. It’s #4149 that introduced this. It says it was created to fix #899 but I can’t understand the issue enough to know how or if changing output.path to require being absolute is required to fix that issue.

    The description of output path does clearly indicate it should be absolute, even though it obviously didn’t need to be before the latest release. Also the docs do show using a full path like so:

    const path = require('path');

module.exports = {
  entry: './path/to/my/entry/file.js',
  output: {
    path: path.resolve(__dirname, 'dist'),
    filename: 'my-first-webpack.bundle.js'
  }
};

    So, for my uses, I’ve just switched to that.

  2. Yeah i’ve been going through my projects, changing it and agree the specific docs do say it should be absolute, whereas the quick start stuff does not (although it does demonstrate use of an absolute path).

    TBH I’m not sure this is the right side of the principle of least astonishment though

  3. since webpack 1 webpack requires output.path to be an absolute path. This hasn’t changed. It’s just validated now.

  5. The solution I arrived at was to use the __dirname variable as it is an absolute path to the build script location. This allows it to be more portable among the dev team because they don’t all end up with a unique URL in there local build script.

    use the __dirname variable*
    path: __dirname.replace('config', 'dist'),

    For the fileName and chunkFileName
    merely adding ./ to the path flips it to a relative path.

    filename: './scripts/app/[name].bundle.js',

Comments are closed.