ERR! UNCAUGHT EXCEPTION on Windows CI with VS2019 and node-sass

[jrr]

Template

• Node Version: node v12.16.1, npm 6.13.4

• Platform:

OS Name:                   Microsoft Windows Server 2019 Datacenter
OS Version:                10.0.17763 N/A Build 17763
System Type:               x64-based PC

• Compiler: VS2019, unsure of specific version.
• Module: node-sass 4.13.1 (I think. yarn why node-gyp indicates that node-sass depends on it.)

Verbose output from yarn install --frozen-lockfile --verbose is attached instead of inlined because it's 23MB: gyp-error.txt

Symptom

During yarn install --frozen-lockfile --verbose, I'm seeing the following error (this is an excerpt from the full log above):

gyp ERR! UNCAUGHT EXCEPTION
gyp ERR! stack Error: spawn C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\15.0\Bin\MSBuild.exe ENOENT
gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:267:19)
gyp ERR! stack     at onErrorNT (internal/child_process.js:469:16)
gyp ERR! stack     at processTicksAndRejections (internal/process/task_queues.js:84:21)
gyp ERR! System Windows_NT 10.0.17763
gyp ERR! command "C:\\hostedtoolcache\\windows\\node\\12.16.1\\x64\\node.exe" "D:\\a\\1\\s\\foobar\\client\\node_modules\\node-gyp\\bin\\node-gyp.js" "rebuild" "--verbose" "--libsass_ext=" "--libsass_cflags=" "--libsass_ldflags=" "--libsass_library="
gyp ERR! cwd D:\a\1\s\foobar\client\node_modules\node-sass
gyp ERR! node -v v12.16.1
gyp ERR! node-gyp -v v3.8.0
gyp ERR! This is a bug in `node-gyp`.
gyp ERR! Try to update node-gyp and file an Issue if it does not help:
gyp ERR!     <https://github.com/nodejs/node-gyp/issues>
Build failed with error code: 7
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.

Details

I'm using Azure Pipeline's windows-latest Windows Agent, which I believe is the same environment that's used for Github Actions.

One thing that catches my eye in the log is some ambiguity about which version of Visual Studio is detected / expected. I see find vs2017 picking up VS2019, and then gyp_main.py invoked with 'msvs_version=2015':

2020-04-05T02:33:25.4472128Z gyp verb find vs2017 Found installation at: C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise
2020-04-05T02:33:25.4472604Z gyp verb find vs2017   - Found Microsoft.VisualStudio.Component.Windows10SDK.16299
2020-04-05T02:33:25.4472995Z gyp verb find vs2017   - Found Microsoft.VisualStudio.Component.Windows10SDK.17134
2020-04-05T02:33:25.4473392Z gyp verb find vs2017   - Found Microsoft.VisualStudio.Component.Windows10SDK.17763
2020-04-05T02:33:25.4473803Z gyp verb find vs2017   - Found Microsoft.VisualStudio.Component.Windows10SDK.18362
2020-04-05T02:33:25.4474195Z gyp verb find vs2017   - Found Microsoft.VisualStudio.Component.VC.Tools.x86.x64
2020-04-05T02:33:25.4474566Z gyp verb find vs2017   - Found Microsoft.VisualStudio.VC.MSBuild.Base
2020-04-05T02:33:25.4474928Z gyp verb find vs2017   - Using this installation with Windows 10 SDK
2020-04-05T02:33:25.4475355Z gyp verb find vs2017 using installation: C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise
2020-04-05T02:33:25.4475751Z gyp verb build/config.gypi creating config file
2020-04-05T02:33:25.4476187Z gyp verb build/config.gypi writing out config file: D:\a\1\s\foobar\client\node_modules\node-sass\build\config.gypi
2020-04-05T02:33:25.4476738Z gyp verb config.gypi checking for gypi file: D:\a\1\s\foobar\client\node_modules\node-sass\config.gypi
2020-04-05T02:33:25.4477342Z gyp verb common.gypi checking for gypi file: D:\a\1\s\foobar\client\node_modules\node-sass\common.gypi
2020-04-05T02:33:25.4477879Z gyp verb gyp gyp format was not specified; forcing "msvs"
2020-04-05T02:33:25.4478229Z gyp info spawn C:\ProgramData\Chocolatey\bin\python2.EXE
2020-04-05T02:33:25.4478476Z gyp info spawn args [
2020-04-05T02:33:25.4478912Z gyp info spawn args   'D:\\a\\1\\s\\foobar\\client\\node_modules\\node-gyp\\gyp\\gyp_main.py',
2020-04-05T02:33:25.4479287Z gyp info spawn args   'binding.gyp',
2020-04-05T02:33:25.4479509Z gyp info spawn args   '-f',
2020-04-05T02:33:25.4479858Z gyp info spawn args   'msvs',
2020-04-05T02:33:25.4480181Z gyp info spawn args   '-G',
2020-04-05T02:33:25.4480415Z gyp info spawn args   'msvs_version=2015',
2020-04-05T02:33:25.4480645Z gyp info spawn args   '-I',
2020-04-05T02:33:25.4481015Z gyp info spawn args   'D:\\a\\1\\s\\foobar\\client\\node_modules\\node-sass\\build\\config.gypi',
2020-04-05T02:33:25.4481362Z gyp info spawn args   '-I',
2020-04-05T02:33:25.4481697Z gyp info spawn args   'D:\\a\\1\\s\\foobar\\client\\node_modules\\node-gyp\\addon.gypi',
2020-04-05T02:33:25.4482058Z gyp info spawn args   '-I',
2020-04-05T02:33:25.4482547Z gyp info spawn args   'C:\\Users\\VssAdministrator\\.node-gyp\\12.16.1\\include\\node\\common.gypi',
2020-04-05T02:33:25.4482927Z gyp info spawn args   '-Dlibrary=shared_library',
2020-04-05T02:33:25.4483200Z gyp info spawn args   '-Dvisibility=default',
2020-04-05T02:33:25.4483578Z gyp info spawn args   '-Dnode_root_dir=C:\\Users\\VssAdministrator\\.node-gyp\\12.16.1',
2020-04-05T02:33:25.4484114Z gyp info spawn args   '-Dnode_gyp_dir=D:\\a\\1\\s\\foobar\\client\\node_modules\\node-gyp',
2020-04-05T02:33:25.4484631Z gyp info spawn args   '-Dnode_lib_file=C:\\Users\\VssAdministrator\\.node-gyp\\12.16.1\\<(target_arch)\\node.lib',
2020-04-05T02:33:25.4485170Z gyp info spawn args   '-Dmodule_root_dir=D:\\a\\1\\s\\foobar\\client\\node_modules\\node-sass',
2020-04-05T02:33:25.4485547Z gyp info spawn args   '-Dnode_engine=v8',
2020-04-05T02:33:25.4485794Z gyp info spawn args   '--depth=.',
2020-04-05T02:33:25.4486047Z gyp info spawn args   '--no-parallel',
2020-04-05T02:33:25.4486301Z gyp info spawn args   '--generator-output',
2020-04-05T02:33:25.4486658Z gyp info spawn args   'D:\\a\\1\\s\\foobar\\client\\node_modules\\node-sass\\build',
2020-04-05T02:33:25.4487015Z gyp info spawn args   '-Goutput_dir=.'
2020-04-05T02:33:25.4487227Z gyp info spawn args ]

Potential workaround

From googling around, it looks VS2019 support arrived in node-gyp 5, but I'm on 3.8.0.

I've set a yarn resolution forcing node-gyp@6.1.0, and after a couple green builds I'm cautiously optimistic that I've resolved the issue.

Questions

1. Is this in fact the issue? (node-gyp v3.8.0 not supporting VS2019)
2. Is there a preferred way of working around this when node-gyp is a transitive dependency?
3. Can anything be done to make the old version of node-gyp fail in a more helpful manner? (I think this will hit anyone using the current version of node-sass on one of the biggest Windows CI hosts. It'd be great if they could get an error telling them what to do!)

[cclauss]

I've set a yarn resolution forcing node-gyp@6.1.0

Awesome. It is right and proper to upgrade from node-gyp@3.8.0 to node-gyp@6.1.0 for compatibility with both Python 3 and VS2019.

From https://github.com/nodejs/node-gyp/blob/master/CHANGELOG.md we can see that #1762 landed in v5.0.0.

[cclauss]

#1753 (comment) @jrr Can we close?

[jrr]

@cclauss before closing I'd like to explore making things better for those that follow.

Ideally, it'd be great if when you install an old version of node-gyp, it could print some kind of post-install warning about compiler compatibility. I'm not sure whether it's possible to add that to an already-published package without publishing a new version, though.

At minimum, perhaps we could put a big compiler compatibility table at the top of the Readme?

[cclauss]

Your review please on #2096

[Dico200]

I ran into the same problem.

[bnoordhuis]

#2096 landed so I think this is good to close.