Skip to content

build: add engines field for bundlers and devEngines field for root #1705

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

Open
Mister-Hope wants to merge 3 commits into
base: main
Choose a base branch
from
+19 −2
Open

build: add engines field for bundlers and devEngines field for root #1705

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
48d3be3
build: add engines field for bundlers and devEngines field for root
Mister-Hope May 15, 2026
fecb375
build: tweaks
Mister-Hope May 16, 2026
ac5c548
Merge branch 'main' into engine
Mister-Hope May 20, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 12 additions & 1 deletion package.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -53,5 +53,16 @@
"oxfmt --no-error-on-unmatched-pattern"
]
},
"packageManager": "pnpm@11.0.8"
"devEngines": {
"packageManager": {
"name": "pnpm",
"version": "11.1.2",
"onFail": "download"
},
Comment on lines +56 to +61
Copy link
Copy Markdown
Member Author

@Mister-Hope Mister-Hope May 16, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We do not, npm v11 stops with this field.

"runtime": {
"name": "node",
"version": "^22.18.0 || ^24.0.0 || ^26.0.0",
Copy link
Copy Markdown
Member

@meteorlxy meteorlxy May 15, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The purpose of the root package.json changes are different. Let's split it to a separate PR. Also this comment is valid

Copy link
Copy Markdown
Member Author

@Mister-Hope Mister-Hope May 16, 2026 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, this is invalid. If you want node e2e test, then runtime MUST be allowed to use v22 and v26. And we do have such tests.

pnpm v11 will throw error if it find itself running on node22 with strict runtime setting.

Copy link
Copy Markdown
Member

@meteorlxy meteorlxy May 18, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Got it. But then why do we need this field? We'll always use .node-version for locking dev env?

Copy link
Copy Markdown
Member Author

@Mister-Hope Mister-Hope May 18, 2026 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

.node-version file is not standard.

A GitHub user now will receive error msg if he is not running on these versions. This ensures any developers using correct node version to develop.

Copy link
Copy Markdown
Member

@meteorlxy meteorlxy May 18, 2026 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What we want is consistent node version instead of 'correct' node version, just like the lock file. That's the purpose of .node-version and why Copilot left this comment

Copy link
Copy Markdown
Member Author

@Mister-Hope Mister-Hope May 18, 2026 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, that's the purpose of .node-version. I can change back the default behavior for reading a constant version at .node-version.

But as we are not a project that interacts with V8 engine's apis, so we should trust node's semver. Testing on the latest patch of a major is better at testing. We ensure our project is runable on latest patch, and since we are runable on previous versions, then we are likely not breaking anything.

Unlike pure javascript pkgs, our project is a node-based tool, so letting our e2e test running on real, latest node versions is better. That fits our users' env.

Only if we are developing a pure javascript package, fixing the node version could then be a better way. In this cases, we trust our packing tool and a stable testing env is our major concern.

"onFail": "error"
}
}
}
3 changes: 3 additions & 0 deletions packages/bundler-vite/package.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -64,5 +64,8 @@
"format": "esm",
"target": "es2023",
"tsconfig": "../../tsconfig.dts.json"
},
"engines": {
"node": "^22.18.0 || ^24.0.0 || ^26.0.0"
}
}
3 changes: 3 additions & 0 deletions packages/bundler-webpack/package.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -67,5 +67,8 @@
"webpack-dev-server": "^5.2.3",
"webpack-merge": "^6.0.1",
"webpack-v5-chain": "^1.1.0"
},
"engines": {
"node": "^22.18.0 || ^24.0.0 || ^26.0.0"
}
}
2 changes: 1 addition & 1 deletion packages/vuepress/package.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -89,6 +89,6 @@
"tsconfig": "../../tsconfig.dts.json"
},
"engines": {
"node": ">=22.18.0"
"node": "^22.18.0 || ^24.0.0 || ^26.0.0"
Comment thread
Mister-Hope marked this conversation as resolved.
Outdated
}
}
Loading