-
Notifications
You must be signed in to change notification settings - Fork 205
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
Support Node 18 #6489
Comments
When trying to run the
This seems to be caused by mozilla/source-map#454, fixed with
|
Thanks for the report. We had an internal report of a similar error. For now we recommend you use Node 16 LTS with pismoA. We may consider an intermediary patch release if we can guarantee the update is compatible with the current release. |
@sigv according to the upgrade instructions, please use Node 16. We will not be supporting Node 18 for |
Understandable. Looking forward to having Current LTS supported on the next version then 🤞🏻 |
This comment was marked as duplicate.
This comment was marked as duplicate.
This comment was marked as duplicate.
This comment was marked as duplicate.
Curiously, in the experiment at #6549 , when I locally run the same yarn test test/swingsetTests/makeKind/test-makeKind.js under Node v18, it works. |
The `source-map@0.7.4` update is important for enabling Node.js v18 compatibility. Older versions use a `typeof fetch === 'function'` check to enable browser-specific behavior. With this release however, the browser check is moved to whether `window` is defined and matches `this` value at check time. Node.js 18 has a `fetch` function, so older `source-map` versions incorrectly flag it as 'browser'. None of Node.js versions have a `this === window` situation going on. This is a change on the path to Node.js 18 compatibility route, in anticipation of Agoric#6489 offering official support down the line.
With #6560 (
|
The `source-map@0.7.4` update is important for enabling Node.js v18 compatibility. Older versions use a `typeof fetch === 'function'` check to enable browser-specific behavior. With this release however, the browser check is moved to whether `window` is defined and matches `this` value at check time. Node.js 18 has a `fetch` function, so older `source-map` versions incorrectly flag it as 'browser'. None of Node.js versions have a `this === window` situation going on. This is a change on the path to Node.js 18 compatibility route, in anticipation of Agoric#6489 offering official support down the line.
The `source-map@0.7.4` update is important for enabling Node.js v18 compatibility. Older versions use a `typeof fetch === 'function'` check to enable browser-specific behavior. With this release however, the browser check is moved to whether `window` is defined and matches `this` value at check time. Node.js 18 has a `fetch` function, so older `source-map` versions incorrectly flag it as 'browser'. None of Node.js versions have a `this === window` situation going on. This is a change on the path to Node.js 18 compatibility route, in anticipation of #6489 offering official support down the line.
We need to add CI tests to ensure continuous Node 18 compatibility (and maybe a round of manual end to end testing on node 18) |
Node.js 14.x is retained as the default, just as it was before, considering it is Maintenance LTS set to EOL next year (2023-04-30). This change adds Node.js 18.x in all the places where workflows previously were building with Node.js 16.x - either as addition to it where multiple version are provided, or as an upgrade where only one version is used. This finishes up the bulk of Agoric#6489, however manual testing of compatibility should be conducted further before that.
I understand this is of fairly low priority to the team, so to keep the ball moving #6599 is available with the test suite enabling Node.js 18.x. Further manual testing can be conducted at a later time as well. |
Node.js 14.x is retained as the default, just as it was before, considering it is Maintenance LTS set to EOL next year (2023-04-30). This change adds Node.js 18.x in all the places where workflows previously were building with Node.js 16.x - either as addition to it where multiple version are provided, or as an upgrade where only one version is used. This finishes up the bulk of Agoric#6489, however manual testing of compatibility should be conducted further before that.
Node.js 14.x is retained as the default, just as it was before, considering it is Maintenance LTS set to EOL next year (2023-04-30). This change adds Node.js 18.x in all the places where workflows previously were building with Node.js 16.x - either as addition to it where multiple version are provided, or as an upgrade where only one version is used. This finishes up the bulk of Agoric#6489, however manual testing of compatibility should be conducted further before that.
Node.js 14.x is retained as the default, just as it was before, considering it is Maintenance LTS set to EOL next year (2023-04-30). This change adds Node.js 18.x in all the places where workflows previously were building with Node.js 16.x - either as addition to it where multiple version are provided, or as an upgrade where only one version is used. This finishes up the bulk of Agoric#6489, however manual testing of compatibility should be conducted further before that.
Node.js 14.x is retained as the default, just as it was before, considering it is Maintenance LTS set to EOL next year (2023-04-30). This change adds Node.js 18.x in all the places where workflows previously were building with Node.js 16.x - either as addition to it where multiple version are provided, or as an upgrade where only one version is used. This finishes up the bulk of Agoric#6489, however manual testing of compatibility should be conducted further before that.
Node.js 14.x is retained as the default, just as it was before, considering it is Maintenance LTS set to EOL next year (2023-04-30). This change adds Node.js 18.x in all the places where workflows previously were building with Node.js 16.x - either as addition to it where multiple version are provided, or as an upgrade where only one version is used. This finishes up the bulk of Agoric#6489, however manual testing of compatibility should be conducted further before that.
Node.js 14.x is retained as the default, just as it was before, considering it is Maintenance LTS set to EOL next year (2023-04-30). This change adds Node.js 18.x in all the places where workflows previously were building with Node.js 16.x - either as addition to it where multiple version are provided, or as an upgrade where only one version is used. This finishes up the bulk of Agoric#6489, however manual testing of compatibility should be conducted further before that.
Node.js 14.x is retained as the default, just as it was before, considering it is Maintenance LTS set to EOL next year (2023-04-30). This change adds Node.js 18.x in all the places where workflows previously were building with Node.js 16.x - either as addition to it where multiple version are provided, or as an upgrade where only one version is used. This finishes up the bulk of Agoric#6489, however manual testing of compatibility should be conducted further before that.
@mhofman, do you prefer to update That should be all the Node.js framework changes for pipelines/CI (until Node.js 14 is dropped off in roughly 5 months). Manual testing can be carried out to ensure compatibility, as mentioned in previous commit. |
I think we should keep the recommended / default to 16 right now. This IPv6 default in 18 has me worried about subtle breakage, especially with Docker. |
Makes sense. Then it's just a question of running manual testing before deciding to officially claim Node.js 18 as compatible. Again - thank you! 🤞🏻 |
Node.js 14.x is retained as the default, just as it was before, considering it is Maintenance LTS set to EOL next year (2023-04-30). This change adds Node.js 18.x in all the places where workflows previously were building with Node.js 16.x - either as addition to it where multiple version are provided, or as an upgrade where only one version is used. This finishes up the bulk of #6489, however manual testing of compatibility should be conducted further before that.
The `source-map@0.7.4` update is important for enabling Node.js v18 compatibility. Older versions use a `typeof fetch === 'function'` check to enable browser-specific behavior. With this release however, the browser check is moved to whether `window` is defined and matches `this` value at check time. Node.js 18 has a `fetch` function, so older `source-map` versions incorrectly flag it as 'browser'. None of Node.js versions have a `this === window` situation going on. This is a change on the path to Node.js 18 compatibility route, in anticipation of #6489 offering official support down the line.
What is the Problem Being Solved?
Node 18 is reaching LTS imminently. We should make sure everything works when using node 18.
Description of the Design
Setup a dev env with node 18 and see what breaks
Update CI to also run against node 18.
Security Considerations
None
Test Plan
Yes
The text was updated successfully, but these errors were encountered: