bundledDependencies attempted to be fetched from npm instead
#5998
Comments
ghost
assigned 
|
we are probably iterating over the Likely here: https://github.com/yarnpkg/yarn/blob/master/src/package-request.js#L284 |
|
Any progress on this? Thanks |
|
Hi all, just wanted to chime in. win-wifi's package.json's dependencies section currently looks like this (which works with NPM): I was able to get the installation to work with yarn by using relative file paths: Using Yarn 1.7.0 EDIT: sorry this is win-wifi, same issue though |
|
I don't believe this is actually the issue since the win-bt library does not have the file dependencies listed as the wifi library does. |
|
For what it's worth, this bug seems to be the direct cause of twilio/flex-plugin-builder#2. Similar to the described scenario, only Yarn encounters an authentication error, not a not found error. |
|
👋 from Dependabot and wanted to chime in with another perspective that this bug is currently allowing us to update vulnerable bundled sub-dependencies in yarn (something we can't do in npm). For example, installing FWIW I'm in favour of leaving this bug unfixed because of the security benefit of being able to update vulnerable sub-dependencies 🤠 |
|
I don't think it's good for public libraries to use bundledDependencies normally... In the example you gave not using bundledDependencies at all would also solve it right? I think the more appropriate use case is for applications that won't be published on npm or features that are still in development but can't be published yet. In these cases you may want to share it with other people or enable CI integrations and use bundledDependencies to handle dependencies that are also unpublished. A private registry is another option but bundledDependencies is a lot simpler in many cases. |
|
In tap, I bundle the Simple reproduction case: This is an extraneous dependency, because nothing is depending on ink at the top level. Additionally, it means that
|
|
Want to chime in on this as well, as I really think it should be fixed / is a bug. As of this comment I'm using Similar to @sambostock's scenario above with Considering these are officially documented dependency types for both npm and yarn, I would think these "private bundled dependency" scenarios would be supported. For any |
|
So I think I might attempt a PR for this soon (unless someone else gets to it first). Unfortunately it's a little more complicated than just "if bundled, skip!" when resolving and installing dependencies. For the first pass I think the following might work:
If anyone has more insight or feedback please let me know - thanks! I could also probably look at how FYI also made sure this wasn't already fixed in yarn v2/"berry", and doesn't seem to be: ➤ YN0001: │ HTTPError: @twilio/frame-ui@npm:^0.36.1: Response code 404 (Not Found)
at EventEmitter.<anonymous> (/development/yarn/.yarn/releases/yarn-berry.js:360:59866)
at runMicrotasks (<anonymous>)
at processTicksAndRejections (internal/process/task_queues.js:93:5) |
|
Gogo @chucknelson ! |
The contract that npm has traditionally followed is that a bundled dep, even if invalid, is to be respected. I could be floating a patch, or using a git checkout, or something else that wouldn't be considered kosher, but you should still use the one that I have bundled, because I bundled it for a reason. A bundled dep in
Don't do that. Bundled deps have all their dependencies bundled in the package as well. If you fetch the bundled meta-deps, then you're back to the same problem. |
|
@isaacs Ah, ok. So with the items you’ve mentioned...are we back to “if bundled, don’t attempt download”? If it’s that simple, maybe we also don’t need to track if a dependency is bundled throughout the yarn lifecycle? |
Bundle dependencies will be removed from Yarn 2. We didn't find in the past year enough practical cases to prove that they were worth their maintenance cost, especially when compared to other existing solutions (including but not limited to relative protocols and resolution overrides). (For example, in the current 1000 most downloaded packages, only two use them: grpc for node-pre-gyp, and the npm package itself) |
@arcanis What does "will be removed" mean, exactly? Are you saying that Yarn 2 will remove bundleDependencies from the packages that it unpacks, and (continue to) fetch them as if they were not bundled? That seems... like you're saying "wontfix" to this issue in particular, unless I'm misunderstanding that?
In our user interviews, the most common reported use for bundleDependencies was to ship private dependencies of an app, or libraries that are planning to be published by haven't yet been published. So, most of those wouldn't be published to the public registry. Of course this use case can definitely be accomplished with |
Yes. But also, don't download any bundled meta dependencies either. Eg, if a package
Can't comment on that, as I'm not familiar with yarn's lifecycle. |
|
@chucknelson is a co-worker of mine, so I’m going to add this bit of info
Yes, this is the scenario we find ourselves in / what is blocking our yarn usage: private dependencies in our code (well, a vendor’s code, which makes it worse). |
Yep, pretty much. It's not out of the question that it'll be possible to implement it from a plugin (since it's essentially a kind of automatic
We aim for the v1 to be the "classic" npm replacement it's always been, so if someone wants to provide a patch and fix it on this repo I think we'll merge it. We just won't be adding new features here, as they'll be developed against the v2 trunk instead. Hopefully this will give plenty of time for everyone to migrate, especially since the Yarn versions aren't tied to the Node release - so you can keep using the v1 until you're ready to make the switch.
It's difficult to say without having the exact details of the setup (who's publishing what, why you don't use a private registry bound to a scope, etc), but I have the feeling that this feature is best achieved through our offline mirror. You'd just end up storing the private tarballs in your repository, and everything would work just fine. |
|
@arcanis Offline mirror will cache all dependencies. // packageA/index.ts published as @scope/A
import * from '@scope/B'; // local unpublished code, bundle through a Module Bundler (webpack,rollup)
import * from 'rxjs';// packageC/index.ts published as @scope/C
import { moduleA, moduleB } from '@scope/A'; // consume A & B without having to treat B as a published library
import * from '@angular/core';TLDR: feature-teams on large project will be stuck with npm as soon as they want to bundle local module into their feature module without publish it. |
|
Argh, this is a blocking for me as well 😿 how can I help? Can I submit a PR? |
That would be awesome if you can - I never got around to it I think it is probably still worth it since yarn v1 is still useful as the legacy/"classic" version. |
|
@chucknelson Actually, due to time issues, I ended up just using npm instead... |
|
Not sure if this is still being looked at, but I want to share my use-case (and as of recently, I believe many others): |
|
Closing as we've completely removed support for |
Thanks - appreciate a link to the formal explanation in the v2 docs! |
Do you want to request a feature or report a bug?
What is the current behavior?
A package being installed from the NPM registry with bundled dependencies will look for the bundled dependencies on NPM registry instead of using the bundled versions. If modules don't exist on the npm registry, the install fails saying
If the current behavior is a bug, please provide the steps to reproduce.
This is my module that I've published to npm, it uses bundled dependencies for some windows specific features, so unfortunately this will only work on windows. There are some other prerequisites that are necessary for a full successful install, but it doesn't get to any of those before this bundled dependencies error so it shouldn't be an issue. Alternately, you could potentially use some other module that has bundled dependencies on npm, I just don't know of any specifically that do. Regardless, all you have to do is
yarn addlike so and the error shows up.What is the expected behavior?
Expected to fetch the module and use the dependencies bundled therein instead of looking on NPM for them.
Please mention your node.js, yarn and operating system version.
node:8.9.1 yarn:1.5.1 and 1.7.0 os: Windows 10 v1803 (build 17134.48)
The text was updated successfully, but these errors were encountered: