| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
PR-URL: https://github.com/npm/npm/pull/8782
|
|
It was broken two ways– it expected npm to accept a string for the
list of packages to install. And it expected a install to return
a list of packages added, not a tree.
PR-URL: https://github.com/npm/npm/pull/8782
Fixes: #8766
|
|
Fixes: #8736
PR-URL: https://github.com/npm/npm/pull/8738
|
|
Fixes: #3358
PR-URL: https://github.com/npm/npm/pull/8724
|
|
|
|
This is a huge set of mostly mechanical changes. Going forward, all
changes to the npm source base are expected to comply with `standard`,
and it's been integrated into the test suite to enforce that. There are
a few notes below about specific classes of changes that need to be
handled specially for npm's code base.
standard: "Expected error to be handled."
`standard` only expects errors spelled "err" to be handled.
`npm-registry-mock` never actually invokes its callback with an error,
so in some cases I just changed it to be spelled "er" and called it
good.
standard: "Expected a "break" statement before 'case'."
This behavior is actually on purpose, and I don't feel like rewriting
the affected code right now (or, you know, ever). So I added code
comments disabling the checks in the three applicable changes.
standard: "x is a function."
Rebinding functions created via declarations (as opposed to expressions)
is a no-no?
PR-URL: https://github.com/npm/npm/pull/8668
|
|
This is necessary because the top level lifecycles run commands that
read the node_modules folder to decide what to do. 😕
|
|
|
|
|
|
See FIXME in install for details on how this will need to be reworked.
|
|
Add logging of when they're first used and when they're completed.
|
|
|
|
This is slower, but necessary as a new install could require a tree
rebalance.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This was broken when I refactored to no longer use fetch-package-metadata on
the top level.
|
|
|
|
This is safe to do globally as deps of globals are NEVER hoisted out of
the global. Each global is self contained.
|
|
|
|
|
|
|
|
|
|
|
|
put @ inside <@scope>
simplify completion usage
add [@<version>] to edit
remove extraneous from install
|
|
|
|
|
|
Before it was logged at warning level, even though it's often completely
not something that you as the application developer can do anything
about.
|
|
|
|
|
|
|
|
add unit test
use fn to identify required version
|
|
|
|
Package scopes cause an additional level in the tree structure which
must be considered when resolving the target folders of a package's
peerDependencies.
Fixes #7454.
|
|
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.
|
|
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.
|
|
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.
|
|
`_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
|
|
|
