build: add engines field for bundlers and devEngines field for root#1705
build: add engines field for bundlers and devEngines field for root#1705Mister-Hope wants to merge 2 commits into
Conversation
Coverage Report for CI Build 25954509750Warning Build has drifted: This PR's base is out of sync with its target branch, so coverage data may include unrelated changes. Coverage remained the same at 72.961%Details
Uncovered ChangesNo uncovered changes found. Coverage RegressionsNo coverage regressions found. Coverage Stats
💛 - Coveralls |
There was a problem hiding this comment.
Pull request overview
This PR updates runtime/tooling constraints across the monorepo by tightening Node.js version requirements for published bundler packages and switching the root project to a devEngines-based declaration for Node/pnpm requirements.
Changes:
- Update
@vuepress/vuepressNode engine range to a major-version allowlist (22/24/26). - Add matching
engines.nodeconstraints to@vuepress/bundler-viteand@vuepress/bundler-webpack. - Replace the root
packageManagerpin with adevEnginesdeclaration for pnpm + Node.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| packages/vuepress/package.json | Changes the engines.node range from a broad >= requirement to a major allowlist. |
| packages/bundler-webpack/package.json | Adds engines.node to constrain supported Node majors for the webpack bundler package. |
| packages/bundler-vite/package.json | Adds engines.node to constrain supported Node majors for the vite bundler package. |
| package.json | Removes top-level packageManager pin and adds devEngines for Node + pnpm. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| "devEngines": { | ||
| "packageManager": { | ||
| "name": "pnpm", | ||
| "version": "11.1.2", | ||
| "onFail": "download" | ||
| }, |
There was a problem hiding this comment.
We do not, npm v11 stops with this field.
| }, | ||
| "runtime": { | ||
| "name": "node", | ||
| "version": "^22.18.0 || ^24.0.0 || ^26.0.0", |
There was a problem hiding this comment.
The purpose of the root package.json changes are different. Let's split it to a separate PR. Also this comment is valid
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Got it. But then why do we need this field? We'll always use .node-version for locking dev env?
There was a problem hiding this comment.
.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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
|
@meteorlxy Changed to |
No description provided.