forked from npm/cli
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
[pull] latest from npm:latest #11
Open
pull
wants to merge
1,401
commits into
soloinovator:latest
Choose a base branch
from
npm:latest
base: latest
Could not load branches
Branch not found: {{ refName }}
Could not load tags
Nothing to show
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
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 removes the v9 bug report template and changes the v10 template to specifically mention that it is for bugs for the latest release line. Previously we would bump these issue templates whenever we did a major release. I think it makes more sense to have only a single bug template most of the time and to add templates for old versions when we are offering bug fix support for them. Currently we don't offer bug fixes for the v9 release line. It also removes the `Release 10.x` label which I find to mostly add noise. I think it would be better to have no default release line label, and and instead manually add this label when we identify a bug that only affects a specific release line that we intend to fix. Or if we are supporting multiple versions then we can add the label to the bug template for old versions.
These will be used to generate normal and json error messages in the same format from both commands and the exit handler. This also does a few others things: - makes `did-you-mean` take a package so it can be sync and called more easily from the error handlers - standardize all error messages with 2 space indentation to match the rest of npm
Our existing example present in npm doc was giving warning, so just modified that so that we will not get any warning . Closes: #7302
Dev dep but it fixed the hoisting of @tufjs/models
Our existing example present in npm doc was giving warning. issue: #7302
The first argument to all `log.method()` calls gets formatted differently with a color. So calls to these should always be a short descriptive title or an empty string.
This changes a bunch of commands to use the new `output.buffer` capabilities from `proc-log` as well as the `outputError` helper from `utils/output-error.js`. This also adds a few comments about future display related breaking changes that npm should make. There is some new behavior around `run-script` and how it outputs errors. It now displays the error for each workspace similar to how that error would get displayed when the process exits.
Fixes: #5444 This PR will continue running through all workspaces for `npm view` even when a workspace encounters an `E404` error. This usually happens when you run `npm view -ws` but have private workspaces. A future iteration could log a different message if an `E404` is encountered on a private workspace, but for this PR I wanted to keep it generic since there are a number of reasons a request for a package manifest could 404.
In refactoring this behavior previously plain strings were no longer being passed through JSON.stringify even in json mode. This commit changes that to the previous behavior which fixes the bug in `npm view`. This also required changing the behavior of `npm pkg` which relied on this. Fixes #7537
This converts all remaining commands/utils to use the display layer for formatting their json output
This has no functional difference but matches where we landed for the rest of the commands.
This will fix the `npm cache add` to cache package with same header as it's used in `npm install` by adding extra manifest call with `fullMetadata: true` while caching to match behaviour with install command which internally request manifest with fullMetadata. ## References Closes #7465
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.
See Commits and Changes for more details.
Created by pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )