You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Deprecate mvdan-sh npm package in favor of sh-syntax #1145
I'm more than happy to entirely remove our js/wasm library here - I don't have the knowledge of JS and Wasm, nor the time to invest into it :)
Assuming you're happy to maintain it with updates to the Go module - which shouldn't be too hard as I don't intend to make API breaking changes anytime soon.
@JounQin do you know if I can update the README or description there to point at this issue or your library? I don't seem to be able to. I don't want to publish a new version to update the README, as that would give the impression that the package is maintained, when it is not.
Ah, I managed to do it via npm deprecate mvdan-sh "See https://github.com/mvdan/sh/issues/1145". It seems like the web UI allows deprecating a package, but not with a custom message.
@mvdan I opened this issue, and I still think sh-syntax is the right successor for modern syntax and maintained parser work.
I'm adding this because some browser consumers, including @eslint/shell, still need a pure-JS parser; moving them to a WASM/TLA path would be a larger change. For context: eslint/shell#33 (comment)
If you'd prefer not to keep maintaining the npm package, would you be open to adding me as a maintainer (or transferring mvdan-sh if that's easier)? I'd keep it maintenance-only and preserve the existing API:
the initial parser target would be the newest mvdan/sh release compatible with GopherJS's supported Go version (currently v3.8.0, which fixes the silent $foo#bar bug);
no promise to backport future syntax or match sh-syntax;
when GopherJS supports a newer Go version, move to the newest compatible mvdan/sh release;
keep the README pointing to sh-syntax as the successor.
If you'd rather leave the package as-is, that's completely fine.
I don't think we should attempt to revive the gopherjs-based library. Gopherjs is not fully dead, but it may as well be. The latest Go version they support is Go 1.21, which is over three years old now. It's a dead end.
I agree that a pure JS parser is still a useful thing to have, but it probably needs a redesign without GopherJS.
Hmm... Go 1.21 support is added at 2026-06-26, and the latest commit is 3 days ago, although it doesn't support latest Go, but it still works well enough for pure js case here.
And I really don't know any other solutions to support pure js environment without reimplementing without your library. Do you have any suggestions?
Activity
mvdan commentedon Apr 7, 2025
I'm more than happy to entirely remove our js/wasm library here - I don't have the knowledge of JS and Wasm, nor the time to invest into it :)
Assuming you're happy to maintain it with updates to the Go module - which shouldn't be too hard as I don't intend to make API breaking changes anytime soon.
JounQin commentedon Apr 7, 2025
Indeed! It's very smooth to upgrade. See also un-ts/sh-syntax#104
JounQin commentedon Apr 7, 2025
@mvdan Do you accept a PR for removing
_jsentirely and recommendsh-syntaxin README for js/wasm users?mvdan commentedon Apr 7, 2025
I'll do this myself later today, as I want to include plenty of context for any readers.
chore(deps): update all non-major dependencies (#228)
mvdan commentedon Apr 10, 2025
I am also reminded that, over a year ago, I already wanted to give up on the JS wrapper built with GopherJS: #1018 (comment)
mvdan commentedon Apr 10, 2025
I have also marked https://www.npmjs.com/package/mvdan-sh as deprecated, so that any existing or new users get a warning against using the package. It's way out of date at this point anyway.
@JounQin do you know if I can update the README or description there to point at this issue or your library? I don't seem to be able to. I don't want to publish a new version to update the README, as that would give the impression that the package is maintained, when it is not.
mvdan commentedon Apr 10, 2025
Ah, I managed to do it via
npm deprecate mvdan-sh "See https://github.com/mvdan/sh/issues/1145". It seems like the web UI allows deprecating a package, but not with a custom message._js: drop mvdan-sh JS package built with GopherJS
chore(deps): update dependency prettier-plugin-sh to v0.17.0 (#371)
chore(deps): update dependency prettier-plugin-sh to v0.17.0 (#128)
chore(deps): update dependency prettier-plugin-sh to v0.17.0 (#74)
chore(deps): update dependency prettier-plugin-sh to v0.17.0 (#124)
41 remaining items
chore(deps): update dependency prettier-plugin-sh to v0.17.2 (#5)
chore(deps): update dependency prettier-plugin-sh to v0.17.2 (#9)
chore(deps): update dependency prettier-plugin-sh to v0.17.2 (#14)
chore(deps): update dependency prettier-plugin-sh to v0.17.4 (#12)
chore(deps): update dependency prettier-plugin-sh to v0.17.4 (#18)
chore(deps): update dependency prettier-plugin-sh to v0.17.4 (#15)
chore(deps): update dependency prettier-plugin-sh to v0.17.4 (#14)
chore(deps): update dependency prettier-plugin-sh to v0.18.0 (#649)
chore(deps): update dependency prettier-plugin-sh to v0.18.0 (#649)
chore(deps): update module mvdan.cc/sh/v3/cmd/shfmt to v3.12.0 (hetzn…
chore(deps): bundle mvdan-sh to suppress deprecation warning on install
chore(deps): update dependency prettier-plugin-sh to v0.19.0 (#246)
JounQin commentedon Nov 11, 2026
@mvdan I opened this issue, and I still think sh-syntax is the right successor for modern syntax and maintained parser work.
I'm adding this because some browser consumers, including @eslint/shell, still need a pure-JS parser; moving them to a WASM/TLA path would be a larger change. For context:
eslint/shell#33 (comment)
If you'd prefer not to keep maintaining the npm package, would you be open to adding me as a maintainer (or transferring
mvdan-shif that's easier)? I'd keep it maintenance-only and preserve the existing API:$foo#barbug);If you'd rather leave the package as-is, that's completely fine.
mvdan commentedon Nov 14, 2026
I don't think we should attempt to revive the gopherjs-based library. Gopherjs is not fully dead, but it may as well be. The latest Go version they support is Go 1.21, which is over three years old now. It's a dead end.
I agree that a pure JS parser is still a useful thing to have, but it probably needs a redesign without GopherJS.
JounQin commentedon Nov 15, 2026
Hmm... Go 1.21 support is added at 2026-06-26, and the latest commit is 3 days ago, although it doesn't support latest Go, but it still works well enough for pure js case here.
And I really don't know any other solutions to support pure js environment without reimplementing without your library. Do you have any suggestions?