Skip to content
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 1,389 commits into from May 18, 2021
Merged

pull #1

merged 1,389 commits into from May 18, 2021

Conversation

ShangguanQuail
Copy link
Owner

No description provided.

nlf and others added 30 commits February 22, 2021 09:16
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
PR-URL: #2743
Credit: @isaacs
Close: #2743
Reviewed-by: @nlf
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
When using `npm explain <package>` it's useful to see if the package has
been bundled. This is especially useful when trying to understand the
provenance of a package's content

PR-URL: #2750
Credit: @kumavis
Close: #2750
Reviewed-by: @nlf
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
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
wraithgar and others added 28 commits May 6, 2021 12:46
* fix(sort): avoid locale-dependent sorting issues
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
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
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
Labels
None yet
Projects
None yet