Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Proposal: remove support for the node_syscall extension #1328

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.

Sign up for GitHub

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

Jump to bottom
Open
nevkontakte opened this issue Jul 20, 2024 · 2 comments
Open

Proposal: remove support for the node_syscall extension #1328

nevkontakte opened this issue Jul 20, 2024 · 2 comments
Labels
Proposal
Milestone
JavaScript intero...

Comments

@nevkontakte
Copy link
Member

The extension has been deprecated for about 3 years (since #1111), and has been disabled by default since then. So far I haven't heard of anyone asking to continue supporting it. This extension has known issues in the memory management department and doesn't support all types of arguments (e.g. #993). I am not even sure it builds under the modern node versions.

I would like to do the following:

  1. Move the source code into a separate repository under the gopherjs organization and mark it archived. This will keep sources available in case anyone is using it for some other purpose, and it would clearly indicate its status an unmaintained.
  2. Remove legacy_syscall build tag from the code base.
  3. Remove the option of using different GOOS/GOARCH for user code which was added as a compatibility option in Standardize on a single GOOS/GOARCH and deprecate node-syscall module. #1111 and fix them to GOOS=js GOARCH=ecmascript.

Inviting @flimzy and anyone else to comment.
@flimzy
Copy link
Member

flimzy commented Jul 22, 2024

I'm in principle in favor of the proposal. I'm only concerned that the fact that we haven't done a complete release in quite some time may mean that there may be those using it, who aren't aware yet of the changes.

As such, I wonder if for the next major release (when generics are complete) we could move it to its own repo first, which will make the deprecation status more obvious, and likely bring out of the woodwork anyone who really needs it. Then assuming no major objections, do the rest of the removal for the following major release.

@nevkontakte
Copy link
Member Author

Yeah, that's a fair argument. I'll admit I am a bit overeager to get rid of it because debugging mystery sigfaults was not fun 😅 But making a full release before deprecating it entirely does seem like a responsible way of doing things.

@nevkontakte nevkontakte mentioned this issue Jul 31, 2024
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Proposal
Projects
None yet
Milestone
JavaScript interoperability
Development

No branches or pull requests
2 participants
@nevkontakte @flimzy