**Summary**
Fixes#4650.
Problem is that Verdaccio (and probably Sinopia2) both are affected as they do not return "repository" nor "homepage" in top level data structure.
**Test plan**
Added new test cases. Also, manually tested with and without https://github.com/verdaccio/verdaccio as registry.
**Summary**
Tests started failing on Travis after #4811, somewhat randomly, due to them expecting the unwrapped
output. This PR fixes those expectations and moves normalize-manifest tests to snapshots since
that's easier than updating 40+ JSON files by hand.
**Test plan**
Tests should pass on all platforms and CI and locally.
**Summary**
Replace [babel-preset-node 5](https://github.com/leebenson/babel-preset-node5) and [babel-preset-es2015-node4](https://github.com/jbach/babel-preset-es2015-node4) with babel-preset-env since the first two packages are deprecated and no longer maintained.
The downside is that `preset-env` is has the comprehensive list of plugins for each environment type, whereas previously packages only selected a few that we were using, so our build size increased. I'm curious to see why @yarnpkg/core 's thoughts are on this, and happy to close the PR if we'd rather stick with the old packages.
**Test plan**
Builds should build and tests should pass since there weren't any code changes 😃
**Summary**
[config.js](389e02979a/src/config.js (L336)) determines if yarn runs in a production environment and sets a `production` config variable accordingly. The list command wants to know if it runs in a production environment and uses `isProduction()` to do so, which does look at environment variables, slightly different than the code in `config.js`, leading to inconsistencies in some corner cases. It should just use `config.production` instead.
`isProduction()` isn't used anywhere else and `config.production` should always be preferred, so I removed the whole function. I planned to adapt the tests of `isProduction()` for `config.production`, but the [existing tests](389e02979a/__tests__/integration.js (L82)) for `config.production` already cover all those cases.
**Test plan**
The existing tests for the `list` command still pass when they use `config.production`.
* Display warning when trying to add a package already in "dependency" to "devDependencies" or vice versa.
* Add positive and negative tests for moduleAlreadyInManifest warning
* tidy up code
* fix(info): Use version from `latest` dist-tag instead of the highest one
Fixes#3947. By default, package `version` was set by sorting all the versions and getting the highest
one. Now it's provided via package `latest` dist-tag.
* Fix linter issues by shortening the test description
* Manually mock request
* Add scenario comment from #4804
* fix(resolution): use registry latest if it satisfies requested semver range
Fixes#3560
**Summary**
Mimic behavior in NPM; use the `latest` version in registry if it
satisfies the semver range requests.
Otherwise fallback to `semver.maxSatisfying()`
**Test Plan**
Added unit test to verify behavior.
* fix eslint line len, additional field check
**Summary**
Actual fix: changed fs.readlink to fs.realpath when checking if a symlink is a linked dependency in package-linker.js This fixes yarn removing linked deps when installing or updating.
Fixes#3288, fixes#4770, fixes#4635, fixes#4603.
Potential fix for #3202.
**Test plan**
See https://github.com/yarnpkg/yarn/issues/3288#issuecomment-335955366 for repro steps.
See https://github.com/yarnpkg/yarn/issues/3288#issuecomment-338503103 for my explanation of the problem.
With a real world test scenario this works, but I'm unable to have it break from a unit test. I added a test in the integration suite but with the bug added back in it still passes because both generated paths are identical. I would like some help with the unit test.
**Summary**
Yarn can not handle the `git+https://` dependency format correctly, as described for various versions in #1625. The problem is present in Yarn 1.2.1.
A related problem for `git+ssh://` has been described in #573 and fixed in #3425.
This PR extends the solution from #3425 to use the Git fetcher for any [Git-over-protocol](https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols) URLs.
**Test plan**
Extended the `package-request` unit tests to verify that the correct remote type (git) is used for `git+https://`, while the tarball remote type continues to be used for regular HTTP(S) URLs.
Fixes#4774
**Summary**
Previously package.json comments were being ignored for "dependencies",
"devDependencies", "optionalDependencies".
This change adds "resolutions" to the sections that will ignore
comments.
**Test Plan**
Added unit test to make sure warning is not printed for a comment in a
resolution.
* Allow ${HOME} in .npmrc to work in Windows
Windows doesn't set the HOME environment variable by default, but NPM
has logic to set process.env.HOME based on the current OS home
directory. See
fb28e5868a/lib/config/defaults.js (L81)
Yarn doesn't do this, so configs such as `prefix =
${HOME}/.npm-packages` that work for NPM will cause Yarn to refuse to
run. This commit updates Yarn's behavior to be closer to NPM's.
Unlike NPM, this commit only sets HOME if it's not already set, to avoid
potentially incompatible changes with existing Yarn users.
* Revert "Allow ${HOME} in .npmrc to work in Windows"
This reverts commit 436422d5b90ccd52e6bad67720b54d7f7c59a44f.
* Allow ${HOME} in .npmrc to work in Windows
Windows doesn't set the HOME environment variable by default, but NPM
has logic to set process.env.HOME based on the current OS home
directory. See
fb28e5868a/lib/config/defaults.js (L81)
Yarn doesn't do this, so configs such as `prefix =
${HOME}/.npm-packages` that work for NPM will cause Yarn to refuse to
run. This commit updates Yarn's behavior to be closer to NPM's, by
using a custom/modified environment when processing NPM configurations.
Add a Flow type `Env` to represent a set of environment variables.
* Ensure environment is restored after test
(A separate `describe` block seems like overkill.)
Fixes#4735
Upgrade was calling outdated in a way that would not filter packages that did not need
an upgrade. The led to potential backdate of package if a beta version was in use. Yarn would
backdate to the "older" latest.
Summary
Some older upgrade code I had written had a code path to have getOutdatedPackages() return all packages, not just ones that were actually outdated. My belief had been that it wouldn't cause an issue because upgrading to the same version would just do nothing... but it turns out if you are on a beta version of a package, this would cause upgrade --latest to backdate you to the actual latest.
So for example if you were currently at beta 1.0.3-0 and the registry had latest 1.0.1 then yarn upgrade --latest would backdate you to 1.0.1.
This PR reinstates the filter that only returns versions if the current is less-than the latest, which would in the above example leave the user at 1.0.3-0
Test plan
Added a unit test that would have failed previously, but passes with this PR change.
**Summary**
Fixes#4706, fixes#4359, refs #4513. `this.config.cwd` was being used as the root for bin link paths, rather than `this.config.lockfileFolder`.
**Test plan**
- Added tests for `add` and `remove` commands (#4706)
- Added test for `install` command (#4359)
**Summary**
Fixes#4539. Yarn was resolving peer dependencies from the closest level where the peer dependency was requested
but it was not checking if the peer dependency was in the same subtree. This was causing incorrect
peer dependency resolutions and package duplication when an unrelated subtree has a depedency
satisfying the required peer dependency at the same tree level.
**Test plan**
Added new install integration test that fails without the fix.
**Summary**
`current` and `wanted` version might be the same but `latest` is a new major version
and as current and wanted are compared against each other it results in most outdated entries being white instead of the proper color
Here a before/after screenshot:
**Summary**
Follow up to #4204. We forgot to relay the exit code of the
newly spawned yarn instance when using `yarn-path` which is
causing false negatives especially when using `yarn run`. This
patch relays the exit code of the spawned process.
**Test plan**
Added a new test that fails without the fix.
* Use lockfileFolder for CLI check
* Make "upgrade" work inside workspace packages
Executes "fetchRequestFromCwd" in actual cwd, which ensures
"outdated" and "upgrade" commands in workspace packages
operate on the correct dependencies and preserve unrelated lockfile
entries.
* Support workspaces in outdated and upgrade-interactive
**Summary**
This PR is triggered by https://git.io/vdzI2. It refactors the
code to allow more hosted Git expansions (like GitLab) in a more
flexible way. It also prefers `url.parse` over regular expressions
and removes any hasehs in `GitUrl.repository` results.
**Test plan**
Existing tests should pass along with the hash removal correction.
**Summary**
Follow up to #4238. We were always passing the `registry` key in
registry overrides but its value was `undefined` when an override
was not in place. `Object.assign` doesn't care about that though
so we were overriding the registry all the time, mostly with
`undefined`.
**Test plan**
Added new test case.
* chore(resolver): Minor improvements in resolver code and tests
**Summary**
This is a follow up to #4484 and #4478 which improves the code
around those areas a bit and removes a now-unnecessary `while`
loop.
**Test plan**
Existing tests should pass.
* Fix logic
**Summary**
The change introduced in 96c215c1ce caused tests to fail on node 7 as react-scripts is not compatible with it. This patch adds `--ignore-engines` flag to suppress the warning.
**Test plan**
Tests should pass on Node 7.
**Summary**
Looking at two solutions introduced in #3393 and #3756, the first one doesn't support win32, while the second does, sticking with the second one more beneficial and supports a wider range of OS.
Removed the stuff introduced in #3393 keeping only #3756.
#3756 also introduced config file normalization, so probably second argument to getOption is obsolete, will discover that and submit another PR if that's the case.
**Test plan**
Modified tests appropriately.
**Summary**
Extra command-line arguments to scripts were not being escaped correctly. This patch adds robust shell quoting logic for both Windows and Linux/macOS.
**Test plan**
On *nix, create a `package.json` containing `"scripts":{"echo":"echo"}`. Run `yarn run -s echo -- '$X \"blah\"'`. Expect to observe ` \blah\` prior to this patch, and `$X \"blah\"` after it.
Testing on Windows should be similar, but may require fancier escaping to get the arguments into yarn in the first place. (I don't have access to a Windows box to verify the exact procedure to follow, sorry—but I did confirm that my automated tests succeed in AppVeyor.)
**Summary**
implements #792 - addresses a command line flag --registry to specify a registry that overides yarn/npm configuration for installing dependencies.
**Test plan**
Added new tests.
**Summary**
This is a failing test-case for issue #2636. It tests that bundled dependencies are not correctly being included in the archive created by `yarn pack`.
**Test plan**
Changing the behavior of `pack` to include the bundled dependencies should make this failing test-case pass.
**Summary**
Fixes#4557. Also adds `yarn config current` that lists the current
configuration as JSON for testing purposes.
**Test plan**
Added integration tests.
**Summary**
Fixes#4547 by testing each version against all ranges individually, rather than munging the patterns together to get a single range.
**Test plan**
Existing tests, plus a regression test to repro #4547: "manifest optimization respects versions with alternation"
**Summary**
Fixes#3780, and makes the failing test from #3779 passing.
As a final step of package resolution, for each dependency we check whether any version satisfies all resolved version ranges.
**Test plan**
Fixes an existing (failing) test: "unbound transitive dependencies should not conflict with top level dependency"
**Summary**
Fixes#4457, partially handles #4470. `.yarnrc` argument passing logic was not aligned with
how `commander` works. Even more, `commander`'s boolean logic was
also not used correctly. This patch fixes both, allowing use of
boolean type CLI options both ways (enable/disable) both from the
command line and `.yarnrc` file.
**Test plan**
Added new integration test for getting args from `.yarnrc`.
**Summary**
Lockfile parser fails when the lockfile had Windows-style line
endings with an "Invalid token" error. This is default on Windows
and, say when editing the file using vim, it is not obvious or
trivial that the file endings are in Windows-style. This patch
makes the parser tolareate potential "\r" chars before "\n" while
keeping the existing parsing logic the same.
**Test plan**
Added three new unit tests.
**Summary**
Fixes#2226. Better emulates `npm_config_argv` by passing
`process.argv.slice(2)` as the `original` portion and both the
command name and the script name in `cooked` portion.
**Test case**
Added integration tests.
**Summary**
FORCE_COLOR environment variable allows to force yarn to use
colors. This makes some of tests fail because of comparing
colorized output with plain strings.
For example, if you run a test in environment where
FORCE_COLOR is set you get this failure:
```
FAIL __tests__\index.js
● should add package
expect(received).toEqual(expected)
Expected value to equal:
"success Saved lockfile."
Received:
success Saved lockfile."
```
**Test plan**
Run tests in an environment where `FORCE_COLOR` is enabled. They should pass.
**Summary**
Fixes#4343. Currently there is no way to remove the package prefix inside `.yarnrc` file, this PR add support for `save-exact` in `.yarnrc` as discussed in #4343. Full credit goes to @jambonrose
```
save-exact true
```
One small thing, should `yarn` be backwards compatible with the old behavior which is `save-prefix ''`? We can just add an extra check here for do this. What do you think @BYK?
```js
} else if (exact || Boolean(this.config.getOption('save-exact')) || Boolean(this.config.getOption('save-prefix'))) {
```
**Test plan**
New unit test.
**Summary**
Fixes#4446, fixes#4433, fixes#2688, fixes#2387. Follow up to #3803. The fix in #3893 was
too aggressive, allowing only top-level dependencies to be used in
peer dependency resolution which was incorrect. This patch allows
resolving peer dependencies from the same or higher levels in the
dependency tree.
**Test plan**
Additional unit and integration tests.
