| Age | Commit message (Collapse) | Author |
|---|
|
|
|
It turns out that config-chain allows you to query a specific config
source by type, which allows us to see whether specific config values
were set explicitly on the command line. Who knew? (Aside from @isaacs
and @dominictarr.)
Anyway, doing this required a small, noninvasive change to
test/tap/config-meta.js so that it didn't try to match the entire set of
parameters passed to `config.get` when doing its metaprogramming thing.
Fixes #7661.
|
|
Use `hosted-git-info` directly to ensure that all GitHub URLs are being
run through the same cloning strategy for caching. Fixes #7630.
|
|
Push the new npm-package-arg logic further into the caching logic.
Doesn't quite handle GitHub URLs correctly yet. That will require
depending on hosted-git-info directly.
|
|
Do the minimal upgrade necessary to get tests passing with new hosted
repo metadata. I anticipate the realize-package-specifier update will be
a little more invasive.
|
|
Due to 448efd0eaa6f97af0889bf47efc543a1ea2f8d7e, running `npm shrinkwrap
--dev` caused production dependencies to no longer be included in
npm-shrinkwrap-.json. Whoopsie! Added a regression test to go with the
fix.
Fixes #7641.
|
|
Fixes #7552.
The npm@<3 installer uses an elaborate data tree built in-memory as the
install process runs to track which dependencies have already been seen
in the tree. This allows the installer to determine whether a parent
dependency satisfies the current semver requirement.
However, if one version of a dependency is specified at one level of the
tree, and then a child of that level includes that same dependency
bundled at a different version, and one of *that dependency's* children
depends on this same dependency at yet another version, it will end up
matching against the version _above_ the bundled dependency. This can
lead anyone trying to figure out what's going on into a phantasmagorical
wonderland where nothing is real, and can also produce an inconsistent
installed tree.
The solution is to ensure that the bundled dependency versions are added
to the tree, but in order to do this, we need to know exactly which
version got bundled. This requires a call to readInstalled, because the
version that was bundled isn't included anywhere in the package
metadata. Since readInstalled is slow, installMany will only call it if
it knows there are bundledDependencies for the current package.
|
|
This is obviously no longer experimental, and I'm not sure this comment
belongs here anymore.
|
|
`lib/utils/link.js` already removes the existing paths, so at the very
least this was leading to some redundant logging.
|
|
The log messages are more useful than the generic error emitted by
clobberFail, so make sure they're almost always visible to end users who
might be otherwise confused. Also make them more consistent, and make
the whole file comply with `standard`'s style rules.'
|
|
The amount that resolve() is used is probably overly cautious as-is, but
if we're going to use it, don't use it bare, or it will assume a base of
`process.cwd()`, which is often incorrect.
|
|
Fixes #7579.
We want to know two things with gently-rm:
1. Is the parent directory under npm's control?
(1a. Is the thing to be deleted under that parent directory if so?)
2. Is the thing to be deleted under npm's control?
There are some additional complications, but that's the core of it, so
to make clearer what was going on, I rearranged the code to prioritize
answering those two questions, and added a bunch of comments explaining
what's happening in an effort that that would make clearer *why* the
code is written the way it is.
When npm removes a file or directory, it verifies whether the thing
being removed is under npm's control. This isn't something that can be
ascertained directly, so gentlyRm checks to see if there's a plausible
case that this file was something that was originally installed by npm.
Mostly it just verifies whether either the deletion target or the parent
directory (which could be passed in as the base, or could be the prefix
otherwise) is under one of the paths that npm might have reason to mess
with.
It will also deal with a certain amount of symbolic link trickery, but
symlink verification was overly aggressive before, and has been eased up
some.
|
|
I also sorted the order of the npm-controlled directories to sort prefix
and globalPrefix up to the top, because those are the two most likely
candidates to match.
|
|
`_resolved` isn't guaranteed to be set on the package metadata by this
point in the installation process, and we probably shouldn't
automatically assume that `_from` is set, either.
|
|
test sets up git repo & mock registry -- fragile
test of install --link=false
test of install --link=true
|
|
|
|
|
|
Fixes #6441.
|
|
Test is now self-contained as well.
|
|
|
|
Also, update code coments to be accurate, and extirpate single-letter
variable names. And introduce a params object because those argument
lists were completely ridiculous.
|
|
Fixes #7531.
|
|
|
|
add usage info to publish
move tag-semver check to publish
test publish instead of config
|
|
|
|
In checkGitDir when executing `git config --get remote.origin.url` the gitEnv function is passed to git.whichAndExec instead of the result of that function.
|
|
|
|
|
|
Fixes #4005, #6248.
What's interesting is that the comment in the code seems to indicate
that this was *always* the intent. But somewhere along the line, that
seems to have broken.
This makes 'npm link' be un-done by running 'npm unlink'.
|
|
|
|
|
|
|
|
Fixes #7294.
|
|
Fixes #7354.
|
|
|
|
|
|
Also make tests conform to `standard` while I'm here, to make merging
less painful later.
|
|
|
|
|
|
Fixes #1999, #2716.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
interpret Infinity as 0 for `outdated`
remove depth: 0 from outdated-depth unit test
add child package with outdated dependency to outdated-depth test
new unit test outdated-depth-deep to confirm that
npm outdated --depth=9999 works as expected
|
|
|
|
|
|
You can either print one deprecation warning for a whole class of
deprecated behavior, or print one deprecation warning for each instance
of that behavior.
|
