Age | Commit message (Collapse) | Author |
|
This is used by npm-registry-fetch to set the 'npm-command' HTTP header.
Will be cleaned up in a less ugly way in config refactor part 2.
PR-URL: https://github.com/npm/cli/pull/2903
Credit: @isaacs
Close: #2903
Reviewed-by: @wraithgar
|
|
- Add workspaces-related configs:
- workspace: list of workspaces names/dir to filter for
- workspaces: boolean value to enable/disable workspaces awareness
- adds the proposed note in the docs of each of the commands
that are not affected by these configs.
- Add workspaces support to `npm run-script`
- add ability to serially run lifecycle scripts in workspaces
- add ability to list scripts for all workspaces
- add colors to `npm run` (no args) output
Relates to: https://github.com/npm/rfcs/pull/117
Fixes: https://github.com/npm/statusboard/issues/276
Fixes: https://github.com/npm/statusboard/issues/283
Fixes: https://github.com/npm/statusboard/issues/284
Fixes: https://github.com/npm/statusboard/issues/285
Fixes: https://github.com/npm/statusboard/issues/286
PR-URL: https://github.com/npm/cli/pull/2864
Credit: @ruyadorno
Close: #2864
Reviewed-by: @wraithgar
|
|
This was erroneously removed during a merge conflict
|
|
|
|
Lots of dead code removed thanks to streamlining of logic.
`npm help` `npm <command>` and `npm help-search` are all now separated
concerns, handling their own use cases. `help` calls `help-search` as a
last resort, but `npm <command>` no longer tries to wind its way through
to `help-search` just to get the basic npm usage displayed.
The `did you mean` output has been expanded. It now always suggests top
level commands, scripts, and bins, and suggests them in the way they
should be called.
PR-URL: https://github.com/npm/cli/pull/2859
Credit: @wraithgar
Close: #2859
Reviewed-by: @ruyadorno
|
|
PR-URL: https://github.com/npm/cli/pull/2878
Credit: @isaacs
Close: #2878
Reviewed-by: @isaacs
|
|
|
|
This replaces the multiple separate sets of objects and documentation,
some of which had defaults and/or types, some of which didn't, and cleans
up a lot of configs that are no longer used.
Deprecated configs are now marked, and the approach used to create these
config definitions ensures that it is impossible to create a new config
option that lacks the appropriate data for it.
|
|
When not handled, when there are multiple entries in
this.npm.config.list, it causes crash as described in #2834
The change here merge everything in this.npm.config.list, because as I
observed, the default config is present only at the last entry.
Fix: #2834
Co-authored-by: @wraithgar
PR-URL: https://github.com/npm/cli/pull/2865
Credit: @kenrick95
Close: #2865
Reviewed-by: @isaacs, @wraithgar
|
|
Iterative change moving us towards a more unified config.
No longer pulling config from flatOptions where we don't have to.
PR-URL: https://github.com/npm/cli/pull/2892
Credit: @wraithgar
Close: #2892
Reviewed-by: @ruyadorno
|
|
PR-URL: https://github.com/npm/cli/pull/2831
Credit: @fraqe
Close: #2831
Reviewed-by: @isaacs
|
|
Small refactor of commands to allow usage to be more programmatically
generated, leading us in the direction of more tighly coupling each
command to the params it accepts.
PR-URL: https://github.com/npm/cli/pull/2821
Credit: @wraithgar
Close: #2821
Reviewed-by: @isaacs
|
|
All output that anything wants to make now goes through
`npm.output()`. This is an incremental change getting us
closer to where we want to be with testing.
PR-URL: https://github.com/npm/cli/pull/2795
Credit: @wraithgar
Close: #2795
Reviewed-by: @ruyadorno, @isaacs
|
|
This causes a `cb() not called` error as the promisified
function explodes silently.
PR-URL: https://github.com/npm/cli/pull/2824
Credit: @wraithgar
Close: #2824
Reviewed-by: @ruyadorno
|
|
pacote expects a **where** option that sets the cwd for all its
operations, ref: https://github.com/npm/pacote#options
This change properly sets that option in libnpmdiff options that will
then properly forward it to pacote, this is specially important for when
reading local file system specs.
PR-URL: https://github.com/npm/cli/pull/2822
Credit: @ruyadorno
Close: #2822
Reviewed-by: @wraithgar
|
|
PR-URL: https://github.com/npm/cli/pull/2807
Credit: @kumavis
Close: #2807
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: https://github.com/npm/cli/pull/2789
Credit: @isaacs
Close: #2789
Reviewed-by: @nlf
|
|
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: https://github.com/npm/cli/pull/2772
Credit: @wraithgar
Close: #2772
Reviewed-by: @ruyadorno
|
|
That file must be newer than the others for the code to do what we are
expecting
PR-URL: https://github.com/npm/cli/pull/2782
Credit: @isaacs
Close: #2782
Reviewed-by: @wraithgar
|
|
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: https://github.com/npm/cli/pull/2759
Credit: @wraithgar
Close: #2759
Reviewed-by: @nlf
|
|
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: https://github.com/npm/cli/pull/2750
Credit: @kumavis
Close: #2750
Reviewed-by: @nlf
|
|
|
|
PR-URL: https://github.com/npm/cli/pull/2743
Credit: @isaacs
Close: #2743
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: https://github.com/npm/cli/pull/2753
Credit: @wraithgar
Close: #2753
Reviewed-by: @isaacs
|
|
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: https://github.com/npm/cli/pull/2742
Credit: @isaacs
Close: #2742
Reviewed-by: @nlf
|
|
contructor -> constructor
PR-URL: https://github.com/npm/cli/pull/2729
Credit: @eltociear
Close: #2729
Reviewed-by: @wraithgar
|
|
Less mocking, more intentional testing of things
PR-URL: https://github.com/npm/cli/pull/2717
Credit: @wraithgar
Close: #2717
Reviewed-by: @nlf
|
|
PR-URL: https://github.com/npm/cli/pull/2716
Credit: @nlf
Close: #2716
Reviewed-by: @ljharb, @wraithgar
|
|
PR-URL: https://github.com/npm/cli/pull/2718
Credit: @nlf
Close: #2718
Reviewed-by: @wraithgar
|
|
In this node version, fall back to `util.promisify` of the callback version.
Maybe fixes https://github.com/npm/cli/issues/2623. Maybe fixes https://github.com/npm/cli/issues/2652. Maybe fixes https://github.com/npm/cli/issues/2625.
PR-URL: https://github.com/npm/cli/pull/2654
Credit: @ljharb
Close: #2654
Reviewed-by: @wraithgar, @ruyadorno
|
|
This decouples our tests from depending on the node version being right, and
allows us to run in all of the environments we need to during CI.
PR-URL: https://github.com/npm/cli/pull/2681
Credit: @ljharb
Close: #2681
Reviewed-by: @wraithgar
|
|
If an env script is already defined, run that
instead of the default.
PR-URL: https://github.com/npm/cli/pull/2655
Credit: @isaacs
Close: #2655
Reviewed-by: @ljharb
|
|
The "do you have auth configured" only takes into consideration a hard-coded
"registry" config, which means that if you don't have auth configured for
the npm registry, but you do for the one you have tied to a scope elsewhere
in your npmrc, we would erroneously tell you that to add a token.
This uses the same method that the rest of the publish chain uses to determine
which registry it would be publishing to, then sees if you have auth for THAT registry.
Because that other function does a hard fallback to the npm registry, there is no more
need for the exception we throw if you do not have one configured. Also, the npm cli
already defaults that config item, so you can't even set it to a falsey value if you
wanted
|
|
- remove spawn util, refactor help command
- add tests for read-user-info, minor refactor
- add tests for pulse-till-done util, refactor
- add tests for otplease util
- add tests for open-url util
- remove unused no-progress-while-running util
PR-URL: https://github.com/npm/cli/pull/2601
Credit: @nlf
Close: #2601
Reviewed-by: @ruyadorno, @wraithgar
|
|
|
|
|
|
|
|
Fix: https://github.com/npm/arborist/issues/207
PR-URL: https://github.com/npm/cli/pull/2573
Credit: @isaacs
Close: #2573
Reviewed-by: @nlf
|
|
- As proposed in RFC: https://github.com/npm/rfcs/pull/144
PR-URL: https://github.com/npm/cli/pull/1319
Credit: @ruyadorno
Close: #1319
Reviewed-by: @isaacs
|
|
PR-URL: https://github.com/npm/cli/pull/2445
Credit: @dr-js
Close: #2445
Reviewed-by: @ruyadorno
|
|
|
|
Adds a optionalDependencies to fixtures in order to cover missing LOC
|
|
|
|
correctly identify already linked packages when global prefix is a symlink
PR-URL: https://github.com/npm/cli/pull/2486
Credit: @nlf
Close: #2486
Reviewed-by: @wraithgar
|
|
|
|
Added a test for install too for this specific condition
PR-URL: https://github.com/npm/cli/pull/2455
Credit: @wraithgar
Close: #2455
Reviewed-by: @isaacs
|
|
fixes #2425
PR-URL: https://github.com/npm/cli/pull/2448
Credit: @nlf
Close: #2448
Reviewed-by: @isaacs, @wraithgar, @darcyclarke
|
|
PR-URL: https://github.com/npm/cli/pull/2422
Credit: @buyan302
Close: #2422
Reviewed-by: @isaacs
|
|
|
|
Since we now are using pacote/tar in a way that will rely on the default
process umask setting, and we set file/directory modes explicitly
anyway, there's no need to have a default umask setting that calls
process.umask()
As this method is not worker-thread safe, and is deprecated, it's best
for us to stop using it.
Fix: #1103
PR-URL: https://github.com/npm/cli/pull/2444
Credit: @isaacs
Close: #2444
Reviewed-by: @nlf
|