webpack: 2.3.0 breaks path resolution on Windows

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

What is the current behavior? Webpack fails with error on any path, e.g.: configuration.context: The provided value “d:\projects\project\src” is not an absolute path!

If the current behavior is a bug, please provide the steps to reproduce. Windows 10 Git Bash Node v6.9.1 npm v4.0.0

Create a webpack project and specify a context path, e.g. context: path.resolve(__dirname, 'src')

run webpack with the specified config.

What is the expected behavior? Webpack uses the path as specified.

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. Windows 10 Git Bash Node v6.9.1 npm v4.0.0

About this issue

  • Original URL
  • State: closed
  • Created 7 years ago
  • Reactions: 31
  • Comments: 56 (9 by maintainers)

Commits related to this issue

Most upvoted comments

It definitely IS a breaking change, I’d wish to see some graceful introduction of this change (with a warning message?), not a revolutionary one like it just happened. So many tools set up by default to use a lower case drive letter…

What about this (webpack.config.js):

const path = require('path');
path: path.resolve(__dirname, './dist'),

__dirname refers to the directory where this webpack.config.js lives

@theodorejb use path.resolve(__dirname,“./app”)

I just want to add that windows file systems are typically not case-sensitive. As @estorski already said, this is a breaking change and not expected in a minor version. Please rethink this decision.

Yep, it seems to be more of an “user error” popping up now as the validation was added. First I couldn’t reproduce it at home but then I noticed that I had switched to drive D by cd D:\path. Everything worked but if I used cd d:\path the lower case would blow the validation. In any case this is a breaking change in my opinion. How many people have windows build scripts doing path changes with lower case letters for drives etc…

This happens in standard out of the box windows 10 command prompt.

in (webpack.config.js) const path = require(‘path’); path: path.resolve(__dirname, ‘./dist’), resolved the problem for me thanks @RomkaLTU

Does it matter how you launch the command prompt as the problem happens with path.resolve paths? Currently cannot use webpack 2.3.0 due to this issue.

Yeah, the suggested workaround does work:

const path = require('path');
path: path.resolve(__dirname, './dist'),

But you shouldn’t have to do that. And FWIW, I’m not launching this from a shell that has a lower-cased first drive letter. I’m using Hyper with Powershell, and my prompt looks like this:

PS C:\source\Swyfft\Swyfft.Web>

Well, default prompt (any prompt) does happily switch between lowercase and uppercase when instructed to… The main problem is that tab-completion fixes casing of directories but not of the drive letters. Because of this I tend to usually be working in a lowercase drive-letter path (in ConEmu) as well.

image

It’s an annoyance and for me personally not a big issue, but the moment I upgrade our deps I know every dev is going to come knocking with this (very non-descriptive) error… 😃

This is a TOTAL hack, but it works for me as a short term solution so I can continue using my webpack configurations w/2.3.1. I just wanted to share in case it helps anyone else.

I added a function to my webpack file:

//to be removed upon webpack fix
const pathHack = (_path) => {
    return _path.charAt(0).toUpperCase() + _path.slice(1).toLowerCase();
};

Inside my webpack file, I use that function in my paths so it capitalizes the drive letter:

module.exports = {
    context: pathHack(path.join(__dirname, "source")),
    entry: {
        "server": pathHack(path.join(__dirname, "source/server"))
    },
    output: {
        path: pathHack(path.join(__dirname, "build")),
        filename: "server.js"
    }
}

Hope this helps 😃

Isn’t the point of the validation to check if the path is absolute? In windows C:\ and c:\ are both absolute paths. How webpack/nodejs treats the difference between the paths shouldn’t be concern of the validation?

Running into this issue with commands launched through Jenkins - works fine on the command prompt, but jobs fail from Jenkins

This is caused by a shell launched with a lowercase drive letter. As this will cause problems (i. e. https://github.com/webpack/webpack/issues/2815) the validation prevents it.

How did you launch your shell?

path: __dirname + '/dist', works fine for me

for now, simply replaced first letter to capital and all worked

const capitalizeFirstLetter = (string) => string.charAt(0).toUpperCase() + string.slice(1); output: { path: capitalizeFirstLetter(path.join(__dirname, clientBundleOutputDir)) }, path: capitalizeFirstLetter(path.join(__dirname, './ClientApp/dist'))

@spyter consider revising your comment -

return _path.charAt(0).toUpperCase() + _path.slice(1).toLowerCase();

may fix things on windows, but it breaks them on non-windows OS. The toLowerCase() in the 2nd part isn’t needed and breaks xplat compatibility.

I’m puzzled that people are referring to an ‘incorrectly cased drive-letter’ on Windows as that is not a possibility. Regardless of the reason for the change, on windows c:\ is definitely an absolute path.

That does get webpack to run but, when started from an incorrectly cased drive-letter commandline, might or will give you lots of warnings like these:

WARNING in C:/Projects/project/~/react-dom/lib/getIteratorFn.js
There are multiple modules with names that only differ in casing.
This can lead to unexpected behavior when compiling on a filesystem with other case-semantic.
Use equal casing. Compare these module identifiers:
* C:\Projects\project\node_modules\react-dom\lib\getIteratorFn.js
    Used by 1 module(s), i. e.
    C:\Projects\project\node_modules\react-dom\lib\traverseAllChildren.js
* c:\Projects\project\node_modules\react-dom\lib\getIteratorFn.js
    Used by 1 module(s), i. e.
    c:\Projects\project\node_modules\react-dom\lib\traverseAllChildren.js

Any way around this?

yes ./app is not an absolute path and invalid for output.path

@sokra Our Webpack config needs to run both on local development machines and as part of a CI service (where the absolute output path won’t be the same). What’s the right way to do this if a relative path can’t be used?

@theodorejb for the typo you can do a PR.

@theodorejb yes ./app is not an absolute path and invalid for output.path

@benneq ../../../../target/ is invalid for output.path

@gyandeeps - Yeah, it was a little tricky to find. Go to ‘Manage Jenkins’, then select ‘Configure System’ and finally click the ‘Advanced’ button near the home directory setting. Then you should see the path for the workspace:

image

more info here: https://github.com/nodejs/node/issues/6624

Use uppercase drive letters in shell.

Run this in shell the change the drive letter: cd .. && cd C%cd:~1% (when on the C: drive)

Check your link to git bash for correct drive letter.