Installation fails for @types/<dependency_name> packages #825
Comments
|
I'm seeing the same issue, but failing at step 2 File permissions are totally fine everywhere Node: v6.7.0 EDIT It turns out my specific problem looked very similar, but is totally not, see DefinitelyTyped/DefinitelyTyped#11932 |
|
npm modules that begin with 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) |
|
Everything under the To clarify, dependencies that I have added under |
|
That's interesting, and led me to wonder what Yarn was looking for in the registry for say Say for example I do Edit: Further to the above, it's only the |
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 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). |
|
+1 - this is a big one for us. |
|
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! |
|
I believe this was fixed w/ #975. I just tried Until we get a new release, you could make the following change in // 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)) |
|
Hi, I've made the change above, but it's not fixed the issue. This is what I get when adding a new
That was after running If you then look at the
Whereas if I then run the same
and the It's also worth noting that I get the same error for adding any package, eg. |
|
I experience the same issue on win7 with
|
|
@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 For me, that release fixed it. |
|
it is fixed for me too. |
|
Still seeing this issue on OS X with 0.16 |
|
Hmm, OK... that's at least a very different error than in the OP (which itself actually looks like a duplicate of #759/#950); it looks more like something that could be a symptom of #521. @otbe: What does |
|
@whitelynx you are right. Seems a bit tricky If I remove the company wide proxy registry from my |
|
@whitelynx I updated And the second time
|
vbfox
added a commit
to vbfox/yarn
that referenced
this issue
Oct 21, 2016
It create problems with some servers like ProGet when used as a nuget cache. It's most likely the source of yarnpkg#825 and yarnpkg#1260
vbfox
added a commit
to vbfox/yarn
that referenced
this issue
Oct 22, 2016
It create problems with some servers like ProGet when used as a nuget cache. It's most likely the source of yarnpkg#825 and yarnpkg#1260
|
Still getting the same error when attempting to upgrade a package. An initial install (clean) works fine now though, so it seems that the bug only affects upgrades. Here's the error log: |
vbfox
added a commit
to vbfox/yarn
that referenced
this issue
Oct 24, 2016
It create problems with some servers like ProGet when used as a nuget cache. It's most likely the source of yarnpkg#825 and yarnpkg#1260
sebmck
pushed a commit
that referenced
this issue
Oct 25, 2016
|
This is fixed on master :) let me know if anyone is still hitting this if you clone master and try. |
|
I'm getting this error too 😢 : |
|
Am seeing the same issue on Sounds like a dup of #656 |
|
This bug still occurs... $ yarn But running a second time worked as all other dependencies are already installed, I guess... |
|
Fixed in 0.18.0 |
|
I'm still seeing issue on 0.18.0 and Windows 10 |
This comment was marked as spam.
This comment was marked as spam.
|
Something similar happens here with 0.18.1 and The logfile contains following stack trace: |
|
@roryprimrose @BendingBender @ecozoic I managed to solve that until the bug will be fixed: #2322 |
4 tasks
|
My yarn log: |
|
Is this bug confirmed closed? I'm seeing this error occur when I attempt to install JSDOM offline. It is definitely available in my cache. |
|
@subyraman can you try this with one of the latest nightlies and submit a new issue if you still have an issue? |
|
Reposted in issue #4266 4266 |
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
|
this error shows while yarn add |
|
I found a workaround, by using types-installer, which does work with yarn. |
|
This is still a problem for me on 1.7.0, not sure why is it closed |
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
|
fixed by minor node@17 update. probably was broken previous minor update |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
and others
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.tsfile cannot be found:Following this, installation appears to have failed and no lock file is produced. Running
yarna 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/@typesdirectory 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
yarncommand when there are@types/<dependency_name>dependencies inpackage.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 innode_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
The text was updated successfully, but these errors were encountered: