Don't remove top level node_modules from emscripten package

[sbc100]

That plan is to start using this top level node_modules
directory for any/all node module dependencies.

Ideally the SDK version would with pre-downloaded node_modules
so that users don't need to download stuff on first use.

See emscripten-core/emscripten#5774
See emscripten-core/emscripten#7538

[sbc100]

Ping.

[kripken]

Ah, I'm sorry to say, but I think this code is a dead end at this point. It runs on the mozilla build machines, but no one maintains them and we can't get this fix there (no access). And in the new build machines we envision, they won't be running this code IIUC.

[sbc100]

But its not dead yet right? This code still produces the SDK for pretty much all SDK users. I'm happy to ignore it once we have the alternative running, but for now I don't see any other way to change the SDK contents today.

[kripken]

This repo is a dead end, though - even if this PR were merged, there's no way to get the actual mozilla machines to fetch and use this code. We don't have access to those machines, and I don't think mozilla has anyone that could help us with them (they just want to shut them off asap).

[juj]

This repo is a dead end, though - even if this PR were merged, there's no way to get the actual mozilla machines to fetch and use this code.

Actually, the build machines do git pull this repo on each build, so even if we don't have maintenance access, we could merge this and the CIs would update the code. Although agree that this is a dead end for us.

The emslave repository with the deployment scripts can still be useful as a way to compile+generate downloadable zips of Emscripten tools in a way that is emsdk-compatible, so there is still value you can find in the scripts in this repository.

[kripken]

Oh, I didn't realize that, thanks @juj. Sorry for getting it wrong before @sbc100

lgtm to me then. @juj? (I think only you have write access to this repo?)

[juj]

Yeah, that works.