fix: use real package name for global local packages installation#1685
fix: use real package name for global local packages installation#1685liangmiQwQ wants to merge 7 commits into
Conversation
✅ Deploy Preview for viteplus-preview canceled.
|
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: f017f86dd6
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: f1daa2779f
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if is_local_package_spec(package_name) { | ||
| // We can't resolve local packages for uninstall, follow npm's behavior | ||
| return Err(Error::ConfigError( | ||
| format!( | ||
| "Local path {} can't be resolved, please enter a package name instead", |
There was a problem hiding this comment.
Rejecting all local-looking specs in uninstall breaks migration for users who already installed globals with older versions that stored ./path (or absolute path) as the package identifier in metadata/bin configs. In that state, reinstalling the same package now reports a binary conflict against the legacy path ID, and even --force cannot recover because conflict cleanup calls uninstall with that path-like ID and immediately errors here, leaving users unable to remove/replace the old install through the CLI.
Useful? React with 👍 / 👎.
1 participant
Related to #664.
The current Vite+ will just treat the path inputed as the package name, and because Vite+ uses package name to create directories and manage installation, it will make Vite+ broken as it can be a bad path.
This PR fixes it by resolving the true package name by reading the
package.jsonunder the entered path.