Conversation
kripken
left a comment
There was a problem hiding this comment.
Is there a downside to running npm ci? If this is just meant to save a few seconds, it might be safer to keep doing it to avoid corner cases (such as the node_modules dir being out of date, or maybe we ship only part of the files some day).
|
You are perhaps correct... I was kind thinking that if we ever do end up a situation where the node_modules we ship is not correct in some way we really would like to know about it ASAP. But I guess you are right that this might be safer.. |
|
It would be good to test that the |
f6fc333 to
f0db4b2
Compare
|
I've verified locally that all the emscripten tests pass with the downloaded version of Also, the tests we have in |
|
For me as a developer the ability to quickly install different SDKs without running npm is something I am looking forward to. |
How about adding a test that uses closure? That would give more coverage here of npm stuff. lgtm with that. |
OK.. maybe.. but I'm not sure this repo is where we test "does the SDK work". In general "does it SDK work" is tests by the emscripten-releases builder. If anything this change makes the installed SDK more like the SDK what we already tested there, so it should require less testing than it did before this change. another way of putting it: The requirement for a test that closure works should have been there before this change since emskd itself was installing closure. Now that emsdk just relies on the bundled version don't we need less testing :) But I guess either way its a good smoketest.. even it it should have been there before. |
716217f to
5255421
Compare
|
Added closure test |
[main] Update dependencies from dotnet/arcade
See WebAssembly/waterfall#670