forked from npm/cli
-
Notifications
You must be signed in to change notification settings - Fork 0
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
Update your repo #1
Open
hello-smile6
wants to merge
2,412
commits into
SheepTester-forks:latest
Choose a base branch
from
npm:latest
base: latest
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
lukekarrys
force-pushed
the
latest
branch
2 times, most recently
from
February 23, 2022 18:35
e930921
to
dd63e21
Compare
fritzy
force-pushed
the
latest
branch
3 times, most recently
from
September 14, 2022 23:09
3037d35
to
f3b0c43
Compare
lukekarrys
force-pushed
the
latest
branch
2 times, most recently
from
October 19, 2022 19:50
591d1d1
to
9e74d3e
Compare
This also refactors auth and prompt related files to use promises and new npm-profile behavior
This PR refactors `exit-handler.js` to be a class so that it can more easily track its internal state. It uses this state to now fully distinguish between 3 states: npm never being set, npm not loaded, and exit handler never called. There are some new error messages shown via console.error if we know we are in an unexpected state. This also continues the refactoring started in #7415 to separate concerns between `npm` and `CLI`. Identifying the error message and logging it have been move to `npm` but catching that error and setting the `process.exitCode` are still handled in `exit-handler.js` and `cli/entry.js`. It also moves `command.cmdExec` to `npm` since it never called from within any `command` instance. This lets `npm` only ever call `command.exec` or `command.workspaceExec` now.
This has the effect of adding licenses back into the lockfiles. Based on code in shrinkwrap.js and inventory.js, it appears that lockfiles are supposed to store the license. It's likely that in practice this behavior has not been consistent due to fetching of minifed manifests and packuments. I also attempted to remove the license code from shrinkwrap but that caused many more tests to break. Plus I believe this is the intended behavior, to have licenses in lockfiles based on bug reports like #7384
BREAKING CHANGE: @npmcli/docs now supports node `^20.17.0 || >=22.9.0`
…>=22.9.0` BREAKING CHANGE: @npmcli/smoke-tests now supports node `^20.17.0 || >=22.9.0`
… >=22.9.0` BREAKING CHANGE: @npmcli/mock-globals now supports node `^20.17.0 || >=22.9.0`
…| >=22.9.0` BREAKING CHANGE: @npmcli/mock-registry now supports node `^20.17.0 || >=22.9.0`
BREAKING CHANGE: libnpmversion now supports node `^20.17.0 || >=22.9.0`
BREAKING CHANGE: libnpmteam now supports node `^20.17.0 || >=22.9.0`
BREAKING CHANGE: libnpmsearch now supports node `^20.17.0 || >=22.9.0`
BREAKING CHANGE: libnpmpublish now supports node `^20.17.0 || >=22.9.0`
BREAKING CHANGE: libnpmpack now supports node `^20.17.0 || >=22.9.0`
BREAKING CHANGE: libnpmorg now supports node `^20.17.0 || >=22.9.0`
BREAKING CHANGE: libnpmhook now supports node `^20.17.0 || >=22.9.0`
BREAKING CHANGE: libnpmfund now supports node `^20.17.0 || >=22.9.0`
BREAKING CHANGE: libnpmexec now supports node `^20.17.0 || >=22.9.0`
BREAKING CHANGE: libnpmdiff now supports node `^20.17.0 || >=22.9.0`
BREAKING CHANGE: libnpmaccess now supports node `^20.17.0 || >=22.9.0`
…9.0` BREAKING CHANGE: @npmcli/config now supports node `^20.17.0 || >=22.9.0`
…2.9.0` BREAKING CHANGE: @npmcli/arborist now supports node `^20.17.0 || >=22.9.0`
BREAKING CHANGE: npm now supports node `^20.17.0 || >=22.9.0`
Passing arborist constructor to pacote.manifest call because internally when fetching git deps DirFetcher requires Arborist constructor from GitFetcher https://github.com/npm/pacote/blob/main/CHANGELOG.md#1400-pre3-2022-09-28 - [x] Trying to add some tests Fixes: #6723
adds a DEPENDENCIES.json for programatic use
BREAKING CHANGE: Attestations made by this package will no longer validate in npm versions prior to 10.6.0 Signed-off-by: Brian DeHamer <bdehamer@github.com>
Signed-off-by: Brian DeHamer <bdehamer@github.com>
BREAKING CHANGE: The `npm hook` command has been removed
BREAKING CHANGE: npm will no longer switch to global mode if aliased to "npmg" or "npm-g" etc. [This code](03bd669) is a remnant from when npm defined `bin` entries for itself that included `npm_g` and `npm-g`. npm no longer defines these, and this code should have been removed when those entries were removed. To utilize this today one would have to manually alias npm themselves. What this code does today in practice is make local development very tricky, because if you (like me) use git worktrees, and have a worktree directory that ends in "g", npm will be in global mode when you invoke it as `node .`. This is very "magical" behavior and not at all intuitive. It's best if this just goes away. `npm -g` is explicit and does not require npm trying to guess if you really wanted to be in global mode or not.
<!-- What / Why --> <!-- Describe the request in detail. What it does and why it's being changed. --> See #7854 for the why and more details. I changed the unwrap logic so that it only runs when the result contains one entry and the amount of arguments is one. Otherwise, when multiple arguments are provided the unwrap results in an undefined. Additionally, I think it makes sense to skip the unwrap logic when the result contains one entry and pkg has multiple arguments because you would expect an object. In the existing comment above the if-statement, it is mentioned the CLI should not unwrap at all. I chose not to do this because it is not clear to me if this is a final decision and has a large impact. However, if it is the desired direction, I am happy to do the work. ## References Fixes #7854
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
idk