| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Instead of checking if from is just a URL, use npm-package-arg to figure
out what kind of URL or shorthand it might be, and save that to
package.json.
|
|
* Save the lightest-possibly normalized URL into `package.json` and
package.json _from fields, because read-package-json, read-installed,
and the cache all know how to handle them now.
* Add support for github:, gist:, bitbucket:, and gitlab: shortcut
syntax. GitHub shortcuts will continue to be normalized to org/repo
instead of being saved with a github: prefix (for now).
* If presented with shortcuts, try cloning via git, SSH, and HTTPS (in
that order, skipping any methods that aren't supported by a given
hosting provider).
* No longer prompt for credentials -- it didn't work right with the
spinner, and wasn't guaranteed to work anyway. We may experiment with
doing this a better way in the future. Users can override this by
setting GIT_ASKPASS in their environment if they want to experiment
with interactive cloning, but should also set --no-spin on the npm
command line (or run `npm config set spin=false`).
|
|
Node.js v0.8 will not emit a separate `error` event if the command
could not be found. Exit code 127 is reserved for “command not found”,
see http://tldp.org/LDP/abs/html/exitcodes.html.
|
|
Fixes #7743.
|
|
|
|
A bunch of the tests are now getting more complete from / resolved
information because the contents of rewritten package.json files on disk
are no longer masked by `read-package-json` memoizing fs reads of
package.json files. Part of fixing #7074.
|
|
Eliminates caching of package.json files, which in turn eliminates a
class of liveness problems / incomplete cache invalidation bugs / race
conditions. Also took this opportunity to standardize the file.
Closes #7074.
|
|
Another fix for #7829. Tip of the keyboard to @leopoldfreeman for
pointing out the missing check.
|
|
When checking the remote URL for a repo, if it errors out, stdout may
not be set.
Fixes #7829.
|
|
It turns out that git commands do now log their output
appropriately, and this change was causing misleading output when using
`maybeGithub`, which was exposed by
89ce829a00b526d0518f5cd855c323bffe182af0, which fixed #7630. npm's git
functionality is maybe a little overcomplicated at this point.
|
|
|
|
|
|
This only impacts github modules installed via github shortcuts, eg
npm install project/module
When the module is marked as private.
|
|
|
|
|
|
|
|
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.
|
