The 1.x line is frozen - features and bugfixes now happen on https://github.com/yarnpkg/berry

Running yarn install as part of a build step for a Docker image based on node:7 fails on Travis CI with ENOTEMPTY, EEXISTS errors. It always seems to error on the webdriverio package.

yarn install v0.19.1
[1/4] Resolving packages...
[2/4] Fetching packages...
error An unexpected error occurred: "https://registry.yarnpkg.com/webdriverio/-/webdriverio-4.6.2.tgz: ENOENT: no such file or directory, open '/usr/local/share/.cache/yarn/npm-webdriverio-4.6.2-dd095ee618896a21c8f1b9d4278736d85a64ca0f/lib/protocol/timeouts.js'".

When Travis runs yarn install as part of the install phase it works just fine. The error only happens when building a Docker image.

Repo which reproduces this issue.

node:7 OS: Docker + Travis CI yarn: 0.19.1 package.json yarn.lock

I've tried installing yarn both with npm install -g and with apt and both methods cause the failure on Travis.

Weirdly enough, the image builds successfully on my local machine which runs Ubuntu 16.04.1 LTS with Docker version 1.13.0, build 49bf474.

Do you want to request a feature or report a bug? Bug

What is the current behavior? I cannot install some packages globally when in Windows and using Git Bash. For example, for @nrwl/schematics (but also for @angular/cli) I get

$ yarn global add @nrwl/schematics
yarn global v1.7.0
[1/4] Resolving packages...
error An unexpected error occurred: "https://https://registry.yarnpkg.com/@nrwl/schematics: Not found".

Error log:

  Error: https://registry.yarnpkg.com/@nrwl/schematics: Not found
      at Request.params.callback [as _callback] (C:\Program Files (x86)\Yarn\lib\cli.js:65656:18)
      at Request.self.callback (C:\Program Files (x86)\Yarn\lib\cli.js:134675:22)
      at Request.emit (events.js:159:13)
      at Request.<anonymous> (C:\Program Files (x86)\Yarn\lib\cli.js:135658:10)
      at Request.emit (events.js:159:13)
      at IncomingMessage.<anonymous> (C:\Program Files (x86)\Yarn\lib\cli.js:135578:12)
      at Object.onceWrapper (events.js:254:19)
      at IncomingMessage.emit (events.js:164:20)
      at endReadableNT (_stream_readable.js:1062:12)
      at process._tickCallback (internal/process/next_tick.js:152:19)

In Ubuntu it seems to work just fine. Same if I use the Windows PowerShell instead of Git Bash.

If the current behavior is a bug, please provide the steps to reproduce. See above

What is the expected behavior? That packages are installed

Please mention your node.js, yarn and operating system version.

$ node -v
v9.3.0

$ yarn config list
yarn config v1.7.0
info yarn config
{ 'version-tag-prefix': 'v',
  'version-git-tag': true,
  'version-commit-hooks': true,
  'version-git-sign': false,
  'version-git-message': 'v%s',
  'init-version': '1.0.0',
  'init-license': 'MIT',
  'save-prefix': '^',
  'bin-links': true,
  'ignore-scripts': false,
  'ignore-optional': false,
  registry: 'https://registry.yarnpkg.com',
  'strict-ssl': true,
  'user-agent': 'yarn/1.7.0 npm/? node/v9.3.0 win32 x64',
  lastUpdateCheck: 1527149439512 }
info npm config
{}

Windows 10

Do you want to request a feature or report a bug?

Bug.

What is the current behavior?

It seems that all native packages are rebuilt every time yarn is asked to either add a new package or just install the currently locked.

If the current behavior is a bug, please provide the steps to reproduce.

1. Add some native packages.

yarn add leveldown bcrypt

1. Run yarn again and observe that both of the packages will be rebuilt for no reason.

yarn

The same happens when adding a completely unrelated packages which, as far as I can tell, cannot affect the native packages in any way.

yarn add co

What is the expected behavior?

Native packages should not be rebuilt if there's no reason to do that. Note that #248 seems pretty similar.

Please mention your node.js, yarn and operating system version.

Node.js 6.7.0 Yarn 0.15.1 Ubuntu 12.04

Do you want to request a feature or report a bug? bug

What is the current behavior?

➜  ~  yarn global add create-react-app
yarn global v0.15.1
warning No license field
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
warning [email protected]: The engine "rhino" appears to be invalid.
warning [email protected]: The engine "rhino" appears to be invalid.
[3/4] 🔗  Linking dependencies...
[4/4] 📃  Building fresh packages...
success Installed [email protected] with binaries:
      - create-react-app
✨  Done in 8.43s.
➜  ~  which create-react-app
create-react-app not found

What is the expected behavior?

➜  ~  yarn global add create-react-app
yarn global v0.15.1
warning No license field
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
warning [email protected]: The engine "rhino" appears to be invalid.
warning [email protected]: The engine "rhino" appears to be invalid.
[3/4] 🔗  Linking dependencies...
[4/4] 📃  Building fresh packages...
success Installed [email protected] with binaries:
      - create-react-app
✨  Done in 8.43s.
➜  ~  which create-react-app
/usr/local/bin/create-react-app

Please mention your node.js, yarn and operating system version.

➜  ~  system_profiler SPSoftwareDataType
Software:

    System Software Overview:

      System Version: macOS 10.12 (16A323)
      Kernel Version: Darwin 16.0.0
      Boot Volume: Macintosh HD
      Boot Mode: Normal
      Secure Virtual Memory: Enabled
      System Integrity Protection: Enabled

➜  ~ node --version
v6.7.0
➜  ~  yarn --version
0.15.1

➜  fuc git:(master) yarn install
yarn install v1.3.2
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
info There appears to be trouble with your network connection. Retrying...
info There appears to be trouble with your network connection. Retrying...
info There appears to be trouble with your network connection. Retrying...
info There appears to be trouble with your network connection. Retrying...
error An unexpected error occurred: "http://npm.byted.org/debug/-/debug-2.6.9.tgz: getaddrinfo ENOTFOUND npm.byted.org npm.byted.org:80".
info If you think this is a bug, please open a bug report with the information provided in "/Users/Jimmy/reactjs/react-native/fuc/yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.
➜  fuc git:(master) ✗

I cloned a project and I looked at the value of yarn.lock, package key 'resolved', which starts with 'http://npm.byted.org'.

I think this is the author custom yarn registry, but I can not visit 'http://npm.byted.org', but yarn config did not fix it.

When running yarn install --production it does not install the required dependencies of forever. This seem to be related to havingnodemon in devDependencies.

Error response:

> forever app.js
module.js:457
    throw err;
    ^
Error: Cannot find module 'minimatch'

I've created a test application here: https://github.com/donovan-graham/yarn-example-app

#  Steps to reproduce error
git clone https://github.com/donovan-graham/yarn-example-app.git
cd yarn-example-app
yarn install --production
npm start

#  temporary step to bypass error
rm -rf node_modules
yarn remove nodemon
yarn install --production
npm start

OP's Note: if you are also having this EXACT problem, please upvote this WITHOUT commenting.

Do you want to request a feature or report a bug?

bug

What is the current behavior?

yarn install v0.14.0
info No lockfile found.
[1/4] 🔍  Resolving packages...
error Couldn't find package "<package>" on the "npm" registry.

If the current behavior is a bug, please provide the steps to reproduce.

"devDependencies": {
    "license-builder": "git+ssh://[email protected]/fishrock123/<package>.git",
}

What is the expected behavior?

typical install

Please mention your node.js, yarn and operating system version.

Node.js: v6.6.1-pre Yarn: v0.14.0 (master) OS: OSX 10.10.5

Do you want to request a feature or report a bug? BUG What is the current behavior? Yarn does not honor .npmrc If the current behavior is a bug, please provide the steps to reproduce. We require authentication for one of our repositories and we used to do this by specifying the authentication in .npmrc. This worked up to 0.28.4 but broke in 1.0.0

What is the expected behavior? Honoring the authentication settings in .npmrc

Please mention your node.js, yarn and operating system version. It happens after upgrading yarn to 1.0.0/1.0.1 (have tried both versions). Regardless of OS and nodejs version.

It seem there is no possibility to install package using yarn without touching package.json? (like npm install without --save params). Shouldn't such feature be added?

Do you want to request a feature or report a bug? Bug

What is the current behavior? I have a package which only depends on modules from the npmjs repository. They are predominantly public repositories, however 5 of them are private repositories scoped using an @ symbol. Again, these are hosted on npmjs.

Up until some time today all of them would download an install without issue. However, something has changed and now one of them fails to install with the following error:

error An unexpected error occurred: "http://registry.npmjs.org/@pepperhq/hmac-http-authentication/-/hmac-http-authentication-0.1.2.tgz: Request failed \"404 Not Found\"".

As I stated previously, the other private repositories (all within the same @ scope) download and install as intended. This leads me to think this isn't an authentication issue.

My .npmrc which is in the root of my project and contains my _authToken looks like this:

//registry.npmjs.org/:_authToken=TOKEN_HERE

I have already completed the following activities:

1. Logging in using npm login again to get a fresh accessToken
2. Ensuring the package name is correct (I copied it from the npm website just to be sure)
3. Running rm -rf node_modules && rm yarn.lock && yarn cache clean
4. Removing the offending package from my package.json and attempting to re yarn add it
5. Attempting to run the equivalent npm install --save command. This worked.

If the current behavior is a bug, please provide the steps to reproduce. As I am unsure of the cause I am unsure how to reproduce. Am willing to discuss further on Discord or in comments on this Issue.

What is the expected behavior? I expect Yarn to install all of my private repositories from npmjs

Please mention your node.js, yarn and operating system version. Taken from yarn-error.log

Yarn version: 
  0.20.3

Node version: 
  6.9.5

Platform: 
  darwin x64

NB: I'm creating this issue in the yarn repo, but this is actually a shared issue between yarn and npm.

With the release of npm 5 back in May, the Node ecosystem now has two lockfile-based package managers. This was overall a win for users, and it has been good to see competition in this space.

However now that there are two competing lockfile formats this can create a new problem for users, especially beginning developers.

When npm 5 came out, Heroku added a new failure if an application was submitted with both npm and yarn lockfiles. In the past few months this has become the most common reason Node builds fail on Heroku and these failures account for ~10-12% of all Node build failures on the platform. Thousands of developers hit this every month.

It's surprisingly easy to end up with both in your repository. Even as an experienced developer I've found myself running the wrong tool for a specific project and having to catch myself before commiting. For an inexperienced developer building their first server / react / angular project who might not understand what a package manager, lockfile, or git repo is, this can be highly confusing.

Neither tool will give a warning or error if the other lockfile exists:

❯ ls *lock*   
ls: *lock*: No such file or directory
                                                                                                                                                         
❯ npm --version
5.8.0
                                                                                                                                                         
❯ yarn --version
1.5.1

❯ npm install
npm notice created a lockfile as package-lock.json. You should commit this file.

added 659 packages from 437 contributors in 10.553s
                                                                                                                                                         
❯ yarn install  
yarn install v1.5.1
info No lockfile found.
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
[3/4] 🔗  Linking dependencies...
[4/4] 📃  Building fresh packages...
success Saved lockfile.
✨  Done in 7.67s.
                                                                                                                                                         
❯ ls *lock*          
package-lock.json yarn.lock

This is likely especially true for Yarn users where most of the documentation on the web instructs users to npm install. Users who copy + paste commands from docs or Stack Overflow are likely to end up here.

I've spoken to @zkat and @iarna at npm and @arcanis on yarn, and all agreed that this is an issue that should be addressed, but there was not full agreement on how. Ideally this issue prompts discussion and both tools can agree on how we can help users here.

I've compiled a list of potential mitigations that have been suggested to me:

Potential solutions

Do nothing

Is there a technical reason a user might want two lockfiles? In this case, how can external tools determine which package manager should be used for that application?

Error if the other lockfile exists

Yarn could print an error and exit if package-lock.json exists and vice-versa.

Pros:

• simple and easy to implement
• the user gets an error where they are in a position to immediately fix it

Cons:

• Not a fantastic user experience

Convert the other lockfile

Yarn could read package-lock.json, convert it into yarn.lock, and remove package-lock.json. npm could do the opposite.

Pros:

• great user experience
• users switching tools would not get a new set of dependencies as a side-effect

Cons:

• My understanding is that due to the different dependency resolution strategies this conversion would be lossy both ways
• Requires each tool to add and maintain code to understand the other lockfile
• Lockfile formats may change over time

Delete the other's lockfile

Just remove the other lockfile and create a new one

Pros:

• effectively prevents this situation

Cons:

• surprising behavior
• user gets new set of dependencies

Run the other tool for the user

If yarn sees a package-lock.json but not a yarn.lock it could log a warning and call npm install for the user

Pros:

• User gets what they wanted

Cons:

• Surprising behavior
• somewhat complicated

Add config to package.json to indicate

Add a field in package.json to indicate which package manager a project should use

"package-manager": "yarn"

Pros:

• Explicitly conveys the user's intent

Cons:

• Adds more config for the user

Other?

Maybe I'm missing something that would work better

I am starting script in offline mode: yarn --silent dev

Extra common logs are removed in silent mode, but internet connection warning is ignoring --silent flag, and is throwing warning: You don't appear to have an internet connection. Try the --offline flag to use the cache for registry queries

My package.json file scripts: "dev": "nest start --watch"

My .yarnrc file: --silent true

Yarn version: 1.22.18

Question: Why yarn will visit yarnpkg.com after package installed? My project use yarn,when I installed a local package, yarn visit yarnpkg.com website,is this ok?

Is there some info log after installed. info There appears to be trouble with your network connection. Retrying...

This will cause the CI, CD process to become very slow, especially in an offline network environment.

yarn is appending my scope + %2f to npm GET request

.yarnrc

"@myscope:registry" "https://artifactory.mycompany.com/artifactory/api/npm/myco"

package.json

"dependencies": {
    "@myscope/web-components": "0.0.29",

yarn install --verbose

Performing "GET" request to "https://artifactory.mycompany.com/artifactory/api/npm/myco/@myscope%2fweb-components".

requesting https://artifactory.mycompany.com/artifactory/api/npm/myco/@myscope%2fweb-components expecting  https://artifactory.mycompany.com/artifactory/api/npm/myco/web-components

yarn version 
1.22.19

(This affects yarn 1.x, so I realize this is unlikely to be changed at this point, but I just wanted to note the discrepancy so that we have a place to discuss/reference).

Given a package.json:

{
  "scripts": {
    "first:yarn": "yarn run second --extra",
    "first:npm": "npm run second --extra",
    "second": "echo $npm_config_argv"
  },
}

Then running yarn run first:yarn (with [email protected]) prints:

{"remain":[],"cooked":["run","first:yarn"],"original":["run","first:yarn"]}

Whereas running npm run first:npm (with [email protected]) prints:

{"remain":[],"cooked":["run","second","--extra"],"original":["run","second","--extra"]}

So, the npm behavior is that npm_config_argv reflects the current script regardless of whether that script was invoked as part of a chain of scripts. But the yarn behavior is that npm_config_argv reflects the first script in the chain. In other words, once npm_config_argv has been set by yarn, it never gets updated, even as different scripts are executed.

I believe that yarn should follow the same behavior as npm.

The context for this issue is https://github.com/google/wireit, which needs to understand which arguments have been passed to an npm or yarn script invocation, for enabling its watch mode and understanding the extra arguments to pass to child processes. If one yarn script invokes another, we therefore lose the ability to understand which arguments have been set for the second script. (wireit issue about this behavior: https://github.com/google/wireit/issues/545)

(This issue does not affect yarn 3.x, because yarn 3.x doesn't set the npm_config_argv argument at all. Instead it passes all arguments after yarn run <script> to the argv of the child, which works fine for our purposes.)

$ yarn config set cache-folder /var/build-cache/node

#11 0.602 yarn config v1.22.5
#11 0.647 warning Skipping preferred cache folder "/home/node/.cache/yarn" because it is not writable.
#11 0.647 warning Skipping preferred cache folder "/tmp/.yarn-cache-1000" because it is not writable.
#11 0.652 warning Skipping preferred cache folder "/tmp/.yarn-cache" because it is not writable.
#11 0.657 error Yarn hasn't been able to find a cache folder it can use. Please use the explicit --cache-folder option to tell it what location to use, or make one of the preferred locations writable.

What happened to yarn that it fails to find a cache directory while called to set the cache directory? Looks weird...