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
pull #1
Merged
Merged
pull #1
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
There are a few commands (exec, run-script, and the run-script proxies) where essentially npm is acting like a very fancy shell. It is peculiar and noisy for npm to print a verbose error banner at the end of these commands, since presumably the command itself already did whatever it had to do to report the error appropriately. For example, `npm test` runs a test script, usually outputting test results. Having npm then tell me that my tests failed with exit status 1 and print a debug log, is unnecessary and unwanted. When the error encountered for these commands does not have a non-zero numeric 'code', then we still print the standard npm error reporting messages, because presumably something went wrong OTHER than a process exiting with a non-zero status code. PR-URL: #2742 Credit: @isaacs Close: #2742 Reviewed-by: @nlf
This is a small incremental step in removing some of the complexity surrounding the `npm` object in our code. It moves that object one level up the chain of code, with the end goal being that we will only require it once in the codebase, ultimately allowing us to improve our tests. I also changed the command that it calls to `run-script` because that is the base command. `run` was an alias, and that is one more layer of hoops a developer would have to jump through to find what file in `./lib` is even being referenced here. PR-URL: #2753 Credit: @wraithgar Close: #2753 Reviewed-by: @isaacs
The third heading needed “package” capitalized. PR-URL: #2749 Credit: @MrBrain295 Close: #2749 Reviewed-by: @isaacs
* Do not rely on underscore fields in `package.json` files * [#2736](https://github.com/npm/cli/issue/2736) Do not remove global packages when updating by name Fix: #2736
We also removed the "none" script because we handle a missing script just fine. There is no need to put an empty one in PR-URL: #2759 Credit: @wraithgar Close: #2759 Reviewed-by: @nlf
To make the headings consistent. PR-URL: #2760 Credit: @MrBrain295 Close: #2760 Reviewed-by: @wraithgar
The documentation in this repository is added to the overall npm documentation at https://docs.npmjs.com/, which includes both the documentation for the public registry and the CLI. The documentation site itself also has a navigational hierarchy; since the content is included from the CLI, we also want to ensure that the navigation for that content lives in this repository. This means that this repository is the source of truth for all of the CLI documentation, and we do not need to update two places when we add, edit, or remove CLI documentation. It all lives here. This also teaches the documentation rendering script to identify when the navigation configuration (nav.yml) is missing new pages that were recently added or retains old pages that have recently been deleted. PR-URL: #2775 Credit: @ethomson Close: #2775 Reviewed-by: @wraithgar
PR-URL: #2778 Credit: @christoflemke Close: #2778 Reviewed-by: @wraithgar, @ethomson
That file must be newer than the others for the code to do what we are expecting PR-URL: #2782 Credit: @isaacs Close: #2782 Reviewed-by: @wraithgar
The lifecycle events section was very out of date, and lots of other cleanup needed to happen too PR-URL: #2690 Credit: @wraithgar Close: #2690 Reviewed-by: @ruyadorno
I checked cli's code with Typescript using the tsconfig below. The compiler found a few arguments that are not used, so I removed them. In the case of `npm whoami`, it is clearer that it ignores its `args` and instead relies on `npm.flatOptions`. ```json { "compilerOptions": { "moduleResolution": "node", "module": "commonjs", "resolveJsonModule": true, "target": "es2019", "noImplicitAny": false, "noImplicitThis": true, "strict": true, "maxNodeModuleJsDepth": 0, "noEmit": true, "allowJs": true, "checkJs": true, "types": ["node"], "lib": ["esnext"] }, "include": ["lib"] } ``` PR-URL: #2766 Credit: @sandersn Close: #2766 Reviewed-by: @nlf, @ruyadorno, @Matausi29
Instead of files randomly requiring the npm singleton, we pass it where it needs to go so that tests don't need to do so much require mocking everywhere PR-URL: #2772 Credit: @wraithgar Close: #2772 Reviewed-by: @ruyadorno
1. Set the shebang to /usr/bin/env bash instead of /bin/sh (which might be dash or some other shell) 2. Use Unix-style line endings, not Windows-style (Cygwin accepts either, but mingw bash sometimes objects, and WSL bash always does) 3. Test against paths using wslpath if available, but still pass win32 paths to node.exe, since it is a Windows binary that only knows how to handle Windows paths. This makes npm as installed by the Node.js Windows MSI installer behave properly under WSL, Cygwin, MINGW Git Bash, and the internal MINGW Git Bash when posix CLI utilities are exposed to the cmd.exe shell. The test is not quite as comprehensive as I'd like. It runs on the various Windows bash implementations if they are found in their expected locations, skipping any that are not installed. Short of shipping mingw, cygwin, and wsl as test fixtures, I'm not sure how we could do much better, however. At least, we can use this test to assist debug and catch issues on Windows machines (ours or users who report problems). PR-URL: #2789 Credit: @isaacs Close: #2789 Reviewed-by: @nlf
The searchopts get parsed and added to the query elsewhere, they're not part of the `include` array they are an extra querystring that is added to the search request. PR-URL: #2803 Credit: @wraithgar Close: #2803 Reviewed-by: @ruyadorno
PR-URL: #3198 Credit: @wraithgar Close: #3198 Reviewed-by: @nlf, @darcyclarke
* fix(sort): avoid locale-dependent sorting issues
PR-URL: #3206 Credit: @lukehefson Close: #3206 Reviewed-by: @darcyclarke
These tests periodically fail in CI, 10 milliseconds is very much not enough time to account for fuzziness, and 5 minutes is more than enough precision given the scales of time involved in each test. PR-URL: #3201 Credit: @wraithgar Close: #3201 Reviewed-by: @nlf
PR-URL: #3216 Credit: @mrmlnc Close: #3216 Reviewed-by: @darcyclarke
This adds the 'en' locale to all instances of String.localeCompare within the CLI codebase. Tests added for the cases where we're sorting arbitrary user-generated data. The tests rely on the fact that 'ch' sorts after 'd' in the `'sk'` locale, but ahead of `'d'` in the `'en'` locale. To ensure that this is the default behavior if no locale is specified, `LC_ALL=sk` is set in the test environment. Other instances of `localeCompare` sort data that the cli controls, so no tests were added. Re: #2829 PR-URL: #3203 Credit: @isaacs Close: #3203 Reviewed-by: @ruyadorno
The mocked npm now uses all config defaults, ensuring we don't have bugs from the disconnect between our currently heavily mocked tests and reality. Eventually the npm mock will be closer to reality, this moves the needle. PR-URL: #3211 Credit: @wraithgar Close: #3211 Reviewed-by: @ruyadorno
This was working by coincidence in 7.7.6 and before, and broken in the 7.8.0 refactor. Before, it would see there was no "name" in the spec, and then read your local package.json, and from that get a latest tag. So, if you didn't have a package.json in your CWD it would fail with an ENOENT trying to read it. This fixes it for real, so that if you are asking for info from a git spec, it goes ahead and looks for the `latest` tag (or whatever tag you have configured as your default). PR-URL: #3209 Credit: @wraithgar Close: #3209 Reviewed-by: @ruyadorno
PR-URL: #3237 Credit: @ruyadorno Close: #3237 Reviewed-by: @wraithgar
Errors will make things stop altogether, dunno if we want to bikeshed that here or not PR-URL: #3231 Credit: @wraithgar Close: #3231 Reviewed-by: @ruyadorno
Add workspaces support to `npm fund` - Add lib/workspaces/arborist-cmd.js base class - Add ability to filter fund results to a specific set of workspaces - Added tests and docs Fixes: npm/statusboard#301 PR-URL: #3241 Credit: @ruyadorno Close: #3241 Reviewed-by: @isaacs
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.
No description provided.