Skip to content
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

Specify package.json engines.node (version compat) field #1970

Closed
webketje opened this issue Jan 27, 2022 · 2 comments
Closed

Specify package.json engines.node (version compat) field #1970

webketje opened this issue Jan 27, 2022 · 2 comments

Comments

@webketje
Copy link

Hi there, great work on esbuild.
For Metalsmith I want to provide a generic JS compiling plugin and ESbuild fits better than other alternatives. However I need to make sure that the core plugins have a specific NodeJS compatibility.
In order to do so, I ran npm info esbuild@latest engines.node but this returns nothing.

Could you add to package.json

"engines": {
  "node": ">=8.17.0"
}

I tested a dev mode build (no minification, no edge cases) with nvm on Node 8.17.0 and it worked. ESbuild might even support earlier versions.

@evanw
Copy link
Owner

evanw commented Jan 28, 2022

I'm surprised that esbuild works with node 8. That reached end of life in 2019. I think it would be a bad policy for esbuild to spend resources supporting a dead platform.

The earliest node version that I'd consider officially supporting is node 12, which is currently in maintenance mode: https://nodejs.org/en/about/releases/. And it looks like node 12 will reach end of life in April of this year.

I could add engines.node and have that just be equal to node's current maintenance LTS version. Is that what you're looking for?

@webketje
Copy link
Author

webketje commented Jan 28, 2022

@evanw I just let you know that the current version does work with Node 8.17.0 (this probably depends on the options passed to the compiler you're using to convert the Go code). It's good practice to add an engines.node field, not sure whether it should reflect the incidentally or actually supported version, but following the LTS EOL is definitely more than good enough

@evanw evanw closed this as completed in 6b16def Jan 29, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants