[pull] latest from npm:latest #2
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
![pull[bot]](https://avatars.githubusercontent.com/in/12910?s=60&v=4){kind=small}
|
Nice to meet you, @pull[bot]. Thank you for creating a pull request.
To close issue send comment "close", to reopen - "reopen", to merge - "merge" |
|
Nice, one of tasks is done |
|
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
lukekarrys
force-pushed
the
latest
branch
2 times, most recently
from
591d1d1
to
9e74d3e
Compare
This will make them actually run again
These tests assert what happens if a shellout command like exec throws unexpected errors by checking what is written to stderr. Progress also gets written to stderr but is not always deterministic due to the nature of calling it via setInterval. So this disables progress for these tests so the stderr assertions can be relied on to be the same.
The logging output was making bare string assertions fail
Originally this was in #7468: We backed off of it while we were rebuilding pacote's packument cache. Now that that's done we can assess this in isolation. I think it makes sense. The packument is cached here, all this is awaiting is normalization and ssri calculation. The only place this potentially does anything is in the premature loading of manifests in `#buildDepStep` when looking at problem edges. We can just wait till we need them and not throw a ton of requests in parallel before we actually need them. Removing the premature loading in problem edges will have to be a separate effort, as it is somehow load bearing
Since npm completion is implemented by calling npm completion -- arg1 this will write a logfile for that command. I noticed this as I was trying to look through my logs for a recent command and found that it had been removed since I used enough tab completions to fill logs-max.
On Windows, `npm help json` and `npm help global` attempt to display `npm-json.html` and `npm-global.html` files which leads to an error because these files have not been generated. This pull request duplicates the `package-json.md` and `folders.md` files in order to generate these files and make the above-mentioned commands functional. Closes: #7374 Co-authored-by: Luke Karrys <luke@lukekarrys.com>
- make uninstall is no longer possible using current source code - Fixes #7488 Signed-off-by: Avinal Kumar <avinal.xlvii@gmail.com> ## References - Refer https://docs.npmjs.com/cli/v7/using-npm/removal#synopsis Signed-off-by: Avinal Kumar <avinal.xlvii@gmail.com>
Err on the side of not displaying things even if they're not valid config
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.
BREAKING CHANGE: `--ignore-scripts` now applies to all lifecycle scripts, include `prepare`
BREAKING CHANGE: When publishing a package with a pre-release version, you must explicitly specify a tag. ref: npm/statusboard#898
Update the list of the cli repos, as its been a while. And fix `which`'s association with its repo.
A few of our tests necessarily use npm's own local version in its package.json, and those tests need to be fixed for the new breaking change that requires an explicit dist tag.
BREAKING CHANGE: `bun.lockb` files are now included in the strict ignore list during packing
Adds bun lockfile, and points to the package.json docs as the authoritative list for ignore rules in the cli docs.
The v10 branch is where new changelog entries for npm@10 get added ref: https://github.com/npm/cli/tree/release/v10
cafile is the correct config key Closes: npm/documentation#1337
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 : )