-
Notifications
You must be signed in to change notification settings - Fork 732
Update node, 15.14.0 -> 16.20.0 #1232
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
This allows us to use the native aarch64 version on MacOS
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm if tests pass
This seems to be working other than the fact that the tests use some versions that aren't supported on arm64 (e.g. 1.39.15 in test.sh). How important is it to test such an old version? Should we keep the very old versions (and just skip that test on M1) or update to a more recent version? |
I think just skip that part of the test when running on arm64 |
Hopefully this is a step towards #1173 |
I wonder if we should announce this change somewhere? I guess its mostly internal facing, but some folks might be using the emsdk version of node directly I guess? |
Yeah, it's probably worth mentioning. Maybe someone would want to disable Rosetta or something and we are the only thing holding them back. In any case it seems worth announcing the node update, and the architecture update would go with that. |
I'm just not sure we have a good place to announce such changes. The other thing that I hadn't previously considered is that this change retro-actively upgrade node for all old versions of emsdk.. so there is a risk we could break old things that used to work. We should be a little careful here.. its a shame we don't have a good mechanism for using this new version only with newer versions of the sdk. |
Hm, yeah. I guess this could only happen if someone uses a new version of emsdk to download an old version of emscripten, and it in theory should only affect the code that emscripten itself runs, right? Hopefully not too many users are using emsdk's node for running their own tests or tooling or something? |
test/test.py
Outdated
@@ -220,7 +226,7 @@ def test_binaryen_from_source(self): | |||
def test_no_32bit(self): | |||
print('test 32-bit error') | |||
emsdk_hacked = hack_emsdk('not is_os_64bit()', 'True') | |||
failing_call_with_output('python %s install latest' % emsdk_hacked, 'this tool is only provided for 64-bit OSes') | |||
failing_call_with_output('python3 %s install latest' % emsdk_hacked, 'this tool is only provided for 64-bit OSes') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Question about this bit: I updated this to python3 because just 'python' doesn't work on mac when updating to the newer XCode. But 'python3' doesn't work on windows.
what is this test trying to check? Is there a better way than this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think that anything currently exists.. maybe probe using shutil.which
to see which one to use (`https://docs.python.org/3/library/shutil.html#shutil.which)
I just realized that test.py runs under python2 on Windows, and we flake8 on both py2 and py3. Now that emscripten requires python3, can we drop py2? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need to support python2 in emsdk still.. at least until we can somehow bootstrap using our own python3.
OK, all the tests are passing now! |
Which comment are you talking about? I do think this is a good idea yes. If it proves problematic to use node 16 with older versions of emsdk we can figure out a way to install node 15 for older versions.. but in the past when we have done these upgrades it hasn't been a problem (IIRC). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@juj just in case ..
.circleci/config.yml
Outdated
# brew itself which takes more than 4 minutes. | ||
HOMEBREW_NO_AUTO_UPDATE: "1" | ||
macos: | ||
xcode: "12.5.1" | ||
xcode: "13.4.1" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually does this dermine the base image to use.. or just the xcode version that is installed in the image? If it changes the base image I think we should revert this line.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure. The reason I changed it though is because there is no 12.5.1 for M1, and I figured it would be good for them to match.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like it does map to the OS version: https://circleci.com/docs/using-macos/#supported-xcode-versions-intel.. so I think we should revert this line.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok. so you're ok with the version not matching between the different hardware?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure. I think the important thing is that we are testing on older versions of macOS where possible
I think we can land this now. |
Thanks for the ping. Looks good, and we should be good on this front overall as well. Btw, I will be on vacation until early August, so my response time will be delayed up a bit until then. |
) This version of node supports wasm-bigint by default, so it will help #19156 Node 16 is over 2 years old, and the node website already provides newer versions both for latest and for LTS. This is possible after emscripten-core/emsdk#829 made the emsdk install a 15.x version by default, and then emscripten-core/emsdk#1232 switched to 16.x.
This allows us to use the native ARM64 version on MacOS. Also update the test scripts to work on ARM64 mac, and skip tests that aren't relevant.
This allows us to use the native aarch64 version on MacOS