2.3.0 breaks path resolution on Windows

11 thoughts on “2.3.0 breaks path resolution on Windows”

1. This is caused by a shell launched with a lowercase drive letter. As this will cause problems (i. e. #2815) the validation prevents it.

   How did you launch your shell?

2. 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.

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

4. 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.

   

   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… 🙂

5. 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..

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

7. 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 🙂

8. 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

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

10. 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>
    

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

Comments are closed.