**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**
[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`.
**Summary**
Use `boolifyWithDefault()` to determine if environment variable values are `true` or `false`. This ensures that all environment variables interpret the same values the same way.
This changes the behavior of `YARN_SILENT` and `YARN_IGNORE_PATH` if they have "unexpected" values, all nonempty stings beside `"0"` and `"false"` are now interpreted as `true`. For example `YARN_SILENT=hello` was interpreted as `false` before, now it is `true`. This makes some sense since those values are truthy in Javascript, but generally makes things more predictable if it works like that for all yarn environment variables.
`YARN_SILENT=true` was also interpreted as `false`. This now definitely makes more sense since it will be interpreted as `true`.
See also [#4811](https://github.com/yarnpkg/yarn/pull/4811#issuecomment-340830589).
**Test plan**
There should be no change to the existing intended functionality and the existing tests still pass.
* 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
**Summary**
Update the accepted semver range to not warn on unknown future versions of node.
**Test plan**
N/A since we don't want to add Node 9 into our build matrix just yet.
**Summary**
Fixes#4615. Disabling all Yarn output in nested commands with `YARN_SILENT` is a bit much, we usually want to see the output. This pull request introduces a new environment variable `YARN_WRAP_OUTPUT` that can be set to `0` to disable the header and footer Yarn normally displays.
Disabling the header/footer might also be useful in other situations, like other tools calling Yarn, so the `YARN_WRAP_OUTPUT` variable has general use.
**Test plan**
Existing integration tests.
* 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**
My recent pull request was to improve the appearance of the progress bar for non-color terminals (PR #4697).
However, @skevy reported a RangeError when running with macOS 10.12, with Node 8.6. This would have been caused by process.stdout.columns returning a negative number.
In this case, this just assumes a default width of 100 characters (as in spinner-progress.js).
**Test plan**
I have not been able to reproduce the condition where `process.tty.columns` returns a negative number, so have verified the logic by considering key cases, e.g., `undefined > 0`, `-1 > 0`.
**Summary**
When Yarn is being run with a different user than the one who created the cache folder, everything
might break (in particular if the cache folder has been created by the root user). This PR fixes this by using the user UID as part of the temporary folder name if possible. If not, it will fallback to the same directory than before.
**Test plan**
The change is small enough that it doesn't need an extra test. We already have a test that makes sure we correctly select a fallback, so adding a new one would only check that it has a specific name, which seems low-signal and prone to break.
**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.
**Summary**
Fixes#756. We have multiple versions of our app and each one uses a different version of node.
Therefore we need to rebuild our `node-sass` module every time we move from one to another.
This PR addresses that by saving the NODE version those artifacts were built with within the `.yarn-integrity` file and triggers forced scripts install (only if the node version is different ofc).
**Test plan**
```
1. Install Node.js 7.x
2. Add the node-sass dependency to the project via Yarn
3. Update Node.js to 8.x (new NODE_VERSION)
4. Run "yarn install" (you should see yarn downloading fresh scripts/binaries)
```
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.)
**Summary**
Fixes#4546.
Pass a `proxy` value to `request` to prevent it from falling back to
checking envirnment variables.
Yarn already gets the env var values through it's configuration and may
have overriden them to it's own liking.
See use case in mentioned issue.
If a `proxy` value is not set, then [this logic](b12a6245d9/request.js (L277)) causes it to check the env vars instead, which will fallback to `http_proxy`. This was preventing the `https_proxy false` config setting from working if environment variables were set, because the request library would fallback to using that instead.
**Test plan**
Manually test with and without https_proxy set in config and in
environment variable.
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**
@gaearon called Yarn out for better peer dependency error messages so this is the first step to make
them more useful and informative.
**Test plan**
Use a repo like `https://github.com/edmorley/yarn-unmet-peerdependency-testcase` to have peer dependency
warnings and observe they now show the path for the package missing the peer dependency. This should
allow people to investigate these errors in an easier fashion.
```
warning "neutrino-preset-airbnb-base > eslint-config-airbnb-base@12.0.2" has unmet peer dependency "eslint@^4.8.0".
warning "neutrino-preset-airbnb-base > eslint-plugin-import@2.7.0" has unmet peer dependency "eslint@2.x - 4.x".
```
**Summary**
Remove entries to clean `*.yml` and `.*.yml` from the default filter list in `.yarnclean`. Instead, include configuration files from common CI and build tools.
- Travis CI
- CircleCI
- AppVeyor
- Codeship
- Wercker
Fixes#4281, fixes#2276.
**Test plan**
```shell
$ yarn autoclean --init
yarn autoclean v1.2.1
[1/1] Creating ".yarnclean"...
info Created ".yarnclean". Please review the contents of this file then run "yarn autoclean --force" to perform a clean.
✨ Done in 0.15s.
$ grep yml .yarnclean
appveyor.yml
circle.yml
codeship-services.yml
codeship-steps.yml
wercker.yml
.travis.yml
```
If the output does not support color, then each render of the progress
bar is added to a single line, which wraps over multiple lines.
As a fallback, a simple carriage return is used to move to the start of
the line, and space characters to clear the line.
**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**
* fix hasHTTPCapability issue with bitbucket shortcut resolver and private repo (#4393)
*bug with a private repo that used like `"module": "bitbucket:team/repo"`*
* fix setRefRemote issue with exotic shortcut resolvers and branch/tag/commit
*bug with a repo that used like `"module": "bitbucket:team/repo#tag"`*
**Test plan**
If I have a private dependency like `"activities": "bitbucket:openagenda/activities"` in my package.json, and I run `yarn install --verbose` then I have this error:
```
[1/4] Resolving packages...
verbose 0.407 Performing "HEAD" request to "https://bitbucket.org/openagenda/es-node".
verbose 0.867 Request "https://bitbucket.org/openagenda/es-node" finished with status code 302.
verbose 0.873 Performing "GET" request to "https://bitbucket.org/openagenda/es-node.git/info/refs?service=git-upload-pack".
verbose 0.98 Request "https://bitbucket.org/openagenda/es-node.git/info/refs?service=git-upload-pack" finished with status code 401.
verbose 0.981 Error: Error connecting to repository. Please, check the url.
at /home/bertho/.config/yarn/global/node_modules/yarn/lib/cli.js:33269:15
at Generator.next (<anonymous>)
at step (/home/bertho/.config/yarn/global/node_modules/yarn/lib/cli.js:92:30)
at /home/bertho/.config/yarn/global/node_modules/yarn/lib/cli.js:103:13
at process._tickCallback (internal/process/next_tick.js:109:7)
error An unexpected error occurred: "Error connecting to repository. Please, check the url.".
info If you think this is a bug, please open a bug report with the information provided in "/home/bertho/OpenAgenda/cibul-node/yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.
```
**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**
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**
Sometimes Yarn saturates the network and sometimes the network itself
has issues, especially on CI and Yarn reports this as a warning. This
should be a simple info message unless it actually completely fails.
This also fixes a flaky integration test with react-scripts.
**Test plan**
`react-scripts` integration test should not be flaky anymore.
**Summary**
Fixes#4546. Previous behavior was that if `.npmrc` or `.yarnrc` contained and `http-proxy` but not an `https-proxy`, HTTPS requests would "fall back" to the `http-proxy`.
This is not always the desired behavior; See #4546 sometimes one protocol needs a proxy and the other does not.
This PR adds the ability to set the `https-proxy` to `false` which will cause Yarn to not use an HTTPS proxy (and not fall-back to the HTTP proxy). This allows the code to treat `undefined` as the setting not being specified (which will fall back to http-proxy) and `false` as the setting being specified, but set to false (which will not use a proxy).
**Test plan**
Tested manually on Windows with Fiddler.
I have no idea how to test this since requests go through the mock http requester when running tests. Suggestions welcome!
**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.
