Installation fails for @types/<dependency_name> packages

[dylanparry]

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

Bug

What is the current behavior?

An error message states that the expected index.d.ts file cannot be found:

yarn install v0.15.1                                                                                                                                                                            
info No lockfile found.                                                                                                                                                                         
[1/4] Resolving packages...                                                                                                                                                                     
warning leaflet-omnivore > csv2geojson > dsv@0.0.3: Replaced by d3-dsv.                                                                                                                         
warning leaflet-omnivore > topojson > queue-async@1.0.7: renamed to d3-queue                                                                                                                    
warning leaflet-omnivore > topojson > d3-geo-projection > brfs > static-module > through2 > xtend > object-keys@0.4.0:                                                                          
[2/4] Fetching packages...                                                                                                                                                                      
warning fsevents@1.0.14: The platform "win32" is incompatible with this module.                                                                                                                 
info "fsevents@1.0.14" is an optional dependency and failed compatibility check. Excluding it from installation.                                                                                
[3/4] Linking dependencies...                                                                                                                                                                   
error ENOENT: no such file or directory, open 'E:\Documents\Visual Studio Projects\Opus4 Core\src\Opus.Web.Scripts\node_modules\@types\leaflet\index.d.ts'                                      
    at Error (native)                                                                                                                                                                           
info Visit http://yarnpkg.com/en/docs/cli/install for documentation about this command.

Following this, installation appears to have failed and no lock file is produced. Running yarn a second time results in a successful installation, however further problems are evident. If I then attempt to install a new @types/<dependency_name> or remove an existing one, I get the same error again.

In the case of removing a dependency, it appears that the entire node_modules/@types directory is deleted when one dependency is removed, resulting in all of the other TypeScript definitions being removed as well.

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

Attempt to initialise with the yarn command when there are @types/<dependency_name> dependencies in package.json, for example:

{
    "name": "opus.web.scripts",
    "version": "1.0.0",
    "private": true,
    "devDependencies": {
        "@types/enzyme": "^2.4.36",
        "@types/leaflet": "^1.0.35",
        "@types/mocha": "^2.2.32",
        "@types/proj4": "^2.3.2",
        "@types/proxyquire": "^1.3.27",
        "@types/react": "^0.14.39",
        "@types/react-dom": "^0.14.17",
        "@types/sinon": "^1.16.31",
        "axios": "^0.15.0",
        "ceylon": "^0.8.0",
        "cross-env": "^3.1.2",
        ...
    },
    "dependencies": {
        ...
    },
    "scripts": {
        ...
    }
}

What is the expected behavior?

The @types/<dependency_name> dependencies should be installed in node_modules/@types/<dependency_name> and a lock file created.

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

Node: v6.3.1
Yarn: 0.15.1
OS: Windows 10 x64

[Meroje]

I'm seeing the same issue, but failing at step 2

yarn install v0.15.1
info No lockfile found.
[1/4] Resolving packages...
warning image-webpack-loader > imagemin-optipng > exec-buffer > execa > cross-spawn-async@2.2.4: cross-spawn no longer requires a build toolchain, use it instead!
[2/4] Fetching packages...
error https://registry.npmjs.org/@types/react-router/-/react-router-2.0.37.tgz: EACCES: permission denied, open '/home/meroje/.yarn-cache/npm-@types/react-router-2.0.37/lib/History.d.ts'
    at Error (native)
info Visit http://yarnpkg.com/en/docs/cli/install for documentation about this command.
yarn  7.38s user 0.51s system 29% cpu 26.385 total

File permissions are totally fine everywhere

Node: v6.7.0
Yarn: 0.15.1
OS: Ubuntu 14.04.5 LTS

EDIT It turns out my specific problem looked very similar, but is totally not, see DefinitelyTyped/DefinitelyTyped#11932

[dominictarr]

npm modules that begin with @ are called "scoped" modules, and are not in the public, replicatable registry. as clarified here: https://github.com/npm/registry/issues/41#issuecomment-236342239
those are in a propeitary part of the npm registry.

yarn could still support scoped modules, but they'll have to go to the npm registry directly for those, instead of to the yarn replica. (edited)

[dylanparry]

Everything under the @types scope is fully available in the public registry—that's how TypeScript definitions are distributed, and how Microsoft suggests people get definitions for external modules written in JavaScript. By not supporting this, Yarn will be effectively not supporting TypeScript developers, which includes anyone using Angular 2 (not that I am).

To clarify, dependencies that I have added under @types install just fine, but adding new dependencies/or removing existing ones cause the entire @types directory to be deleted, forcing me to run the add/remove command twice—the second time restores the directory and all the TypeScript definition files inside it.

[dylanparry]

That's interesting, and led me to wonder what Yarn was looking for in the registry for say @types/react.

Say for example I do yarn outdated, I get an error that one of the @types/* packages cannot be found—it's random depending on which it decides to look up first. It would appear that it tries to look up the metadata at https://registry.yarnpkg.com/@types/react rather than encoding the URL to https://registry.yarnpkg.com/@types%2freact which would return some proper JSON, whereas the former returns an error.

Edit: Further to the above, it's only the / that needs to be encoded. If you encode the full name including the @, then the URL is still broken. Eg. https://registry.yarnpkg.com/%40types%2Freact. So something like encodeURIComponent(name).replace('%40', '@') should do it—not sure where that change would need to be made though.

[kribblo]

@dominictarr

npm modules that begin with @ are called "scoped" modules, and are not in the public, replicatable registry.

Almost true: you can have public, scoped modules as well (I have a few that are published that way), but they do default to private. See --access public at https://docs.npmjs.com/cli/publish

At my company, we have the need to both install public, scoped packages from npmjs and private, scoped packages from our own private repository (which is how I ended up in this issue, trying to find out if that's even possible).

[AdamPD]

+1 - this is a big one for us.

[aecz]

I'll stick to pnpm until this one is solved but really like that Yarn is using a flat tree like NPM 3 and a lock file. Makes it more compatible. Good job!

[kasperlewau]

I believe this was fixed w/ #975.

I just tried yarn add @types/react --save locally and it works on my machine.

---

Until we get a new release, you could make the following change in /usr/local/lib/node_modules/yarn/lib/package-linker.js (or wherever it may be on your system) in the linkBin method:

// from
if (process.platform === 'win32') {
  yield cmdShim(src, dest);
} else {
  yield (_fs || _load_fs()).symlink(src, dest);
  yield (_fs || _load_fs()).chmod(dest, '755');
}

// to
if (process.platform === 'win32') {
  yield cmdShim(src, dest);
} else {
  yield (_fs || _load_fs()).mkdirp(path.dirname(dest)); // <- add this bit
  yield (_fs || _load_fs()).symlink(src, dest);
  yield (_fs || _load_fs()).chmod(dest, '755');
}

...and that should get you going, somewhere.

(osx 10.11.2/node 6.8.0/yarn 0.15.1 (modified))

[dylanparry]

Hi,

I've made the change above, but it's not fixed the issue. This is what I get when adding a new @types/ dependency:

That was after running yarn add @types/react. As you can see from the error, it's attempting to find a file that's not remotely related to the one I was attempting to add, but was previously installed.

If you then look at the node_modules directory, you'll see that the @types and .bin directories are missing:

Whereas if I then run the same yarn add @types/react command again, it adds the package and restores the missing ones:

and the .bin directory is back again too. It seems that this failure is occurring before the point at which the linker has actually ran, and it fails because the @types directory has been deleted for some reason.

It's also worth noting that I get the same error for adding any package, eg. yarn add react or yarn add enzyme result in the same errors about the missing @types directory. It doesn't have to be a @types/* dependency that I'm trying to install.

[likerRr]

I experience the same issue on win7 with yarn add, yarn outdated, yarn upgrade commands.

[whitelynx]

@dylanparry, @likerRr: Are you still seeing this issue with v0.16.0 (released about a day ago) or v0.16.1? I'm on Linux, but with yarn v0.16.0, adding @types/react works fine the first time:

 ~/D/Personal  mkdir yarntest
 ~/D/Personal  cd yarntest/
 ~/D/P/yarntest  yarn init
yarn init v0.16.0
question name (yarntest): 
question version (1.0.0): 
question description: A yarn test
question entry point (index.js): 
question git repository: 
question author: David H. Bronke <whitelynx@gmail.com>
question license (MIT): 
success Saved package.json
Done in 16.11s.
 ~/D/P/yarntest  yarn add @types/react
yarn add v0.16.0
info No lockfile found.
[1/4] Resolving packages...
[2/4] Fetching packages...
[3/4] Linking dependencies...
[4/4] Building fresh packages...
success Saved lockfile.
success Saved 1 new dependency
└─ @types/react@0.14.41
Done in 1.91s.
 ~/D/P/yarntest  yarn --version
0.16.0

For me, that release fixed it.

[hanjukim]

it is fixed for me too.