inconsistent webpack build

[chiefjester]

• Your Windows build number: (Type ver at a Windows Command Prompt)
  Microsoft Windows [Version 10.0.16278.1000]

• What you're doing and what's happening: (Copy&paste specific commands and their output, or include screen shots)

• $ npm run build (getting errors)

• getting erros
  

• $ npm run build (running it again magically fixes it!)

• magically fixes it
  

• What's wrong / what should be happening instead:
  Similar to my issue sometimes I have to invoke the command twice to register #2494 ; This build is a hit or miss, sometimes I need to run the same script 3x to 4x just to get it running. I have my Defender Off.

Seems to me that it can't reach/read the node_modules, looks like another File I/O Issue?

[sunilmut]

@thisguychris - Thanks for your post. Can you please share the full repro steps? Also, can you try the repro on LxFs ex: ~ (home directory) and share your observation?

[chiefjester]

I'm just doing a normal webpack production build, so webpack -p. This code is something internal so I can only share some bits since I'm under NDA.

I'll try to build in the ~/ directory

[chiefjester]

Hi, just reporting back, building it on ~/home
I've consistently not getting the same error. I tried building it 4times and all 4 of them gives me consistent result.

[therealkenc]

I'm just doing a normal webpack production build

Microsoft NT Kernel developers are perhaps not versed on "normal webpack production builds"....

Anyway, there seems to be something to the reports of files/directories disappearing. I haven't seen it myself, but the error from the screencap here is Module not found: Error: Cannot resolve [whatever] in [wherever], which then magically reappears on another run. Which is about the same as #2484, which is unrelated to webpack production builds of the normal or abnormal variety.

[sunilmut]

I am getting a feeling that this is related to #2448 (funny how it's the last two digits swapped from #2484 :)), also, because of the intermittent nature of the issue. #2448 is a regression between builds 16251 and 16278. It would be interesting to see if this issue also appears on build 16251.

[Warblefly]

Sounds familiar. Building big things in lxss fails very occasionally, once or twice in a long build. Attempting the build again gets past the problem, usually. Now testing Insider Build 16288.1, and it most definitely fails in the same way on a DrvFs mounted system.

[Warblefly]

Occasional fails still occur when building exclusively within LxFs within the lxss directory. One or two files vanishing or appearing as directories in building, say, Qt or Gtk+3. This is such a pity, because the system used to be completely reliable both in DrvFs and LxFs.

[sunilmut]

Thanks for the input @Warblefly. Adding @SvenGroot.

[chiefjester]

oh yes, I tried using yarn too. I get about the same results using npm. So this is definitely in WSL and not on nom or yarn. I agree its related to #2448