so, where are the packages stored? how is this more secure than npm? how does this solve the leftpad problem?
leftpad was a social issue. It's been solved by policy on the registry side stopping packages depended on by many others being unpublished.
Yarn – A new package manager for JavaScript
31–40 of 486 posts
Re: Yarn – A new package manager for JavaScript
#32"Linking: Finally, Yarn links everything together by copying all the files needed from the global cache into the local node_modules directory." Stop copying stuff. Just make it global and link. Next step is to make packages immutable and signed. I'm happy with this step and the fact that facebook will be able to push this.
Yeah, that would be much better. But unfortunately the node_modules structure (which yarn is attempting to be fully compatible with) makes that impossible.
The reason is that each package only finds its dependencies relative to its own location. So your second level dependencies cannot vary from project to project unless you do copying.
(Example: AppA and AppB depend on LibX. LibX depends on LibY. Through their deterministic lockfiles, AppA and AppB disagree on which version of LibY to use. There is no way to symlink things together to satisfy that case without copying LibX or altering node's package resolution algorithm.)
Re: Yarn – A new package manager for JavaScript
#33I think the write-up should specify `npm install -g yarnpkg` not `npm install -g yarn`.
Could be worth finding the author of 'yarn' on npm and asking them for the name - it's been unmaintained for 4 years:
Re: Yarn – A new package manager for JavaScript
#34Recently I got annoyed how hard it is to use shrinkwrap in npm and started working on a npm wrapper that would make npm as easy to work with as Ruby Bundler by copying its workflow as closely as possible (https://github.com/szimek/bundlerjs). Thankfully, I don't have to develop it anymore ;) Big thanks to all Yarn developers!
Re: Yarn – A new package manager for JavaScript
#35wow already one of the features i'm loving in yarn is that it tells you which package is firing warnings about package incompatability.
warning electron-prebuilt-compile > electron-compilers > jade@1.11.0: Jade has been renamed to pug, please install the latest version of pug instead of jade
in npm, that would have just said the part after "jade@1.11.0" which was really vague and didn't really make you want to "fix" it because which npm module do you have to go into? who knows because npm (the package manager) didn't tell you.
Re: Yarn – A new package manager for JavaScript
#36"Linking: Finally, Yarn links everything together by copying all the files needed from the global cache into the local node_modules directory." Stop copying stuff. Just make it global and link. Next step is to make packages immutable and signed. I'm happy with this step and the fact that facebook will be able to push this.
This is something I really want to explore more through less-compatible modes. It was the original way yarn worked, but it wasn't compatible enough to be the default mode: https://github.com/yarnpkg/yarn/issues/57
Hmm.. is it still available as a configuration option somewhere? I couldn't find it on the site.
I'm a huge fan of bundler - it's dependency heaven. I'm also a big fan of the rubygems repo. It does not allow changes in released versions.
Even without symlinks it's a much needed improvement in the javascript ecosystem
Re: Yarn – A new package manager for JavaScript
#37"Linking: Finally, Yarn links everything together by copying all the files needed from the global cache into the local node_modules directory." Stop copying stuff. Just make it global and link. Next step is to make packages immutable and signed. I'm happy with this step and the fact that facebook will be able to push this.
This is something I really want to explore more through less-compatible modes. It was the original way yarn worked, but it wasn't compatible enough to be the default mode: https://github.com/yarnpkg/yarn/issues/57
If you do, would love see experiments on that. I do wish NPM would start adding badges or some other meta data to packages that signify that a module has constraints like:
- No native code
- No module state (No multiple singletons, and easily load variants of a module)
- Pure installation, aka no build steps and is fully cacheable via hashing/immutable module patterns
- Is all pure functional
- 100% code coverage
- Etc.
Re: Yarn – A new package manager for JavaScript
#38I wrote a post explaining why I'm psyched to be working on it: TLDR: - open, community governance that will support long-term evolution - the technical details get a lot right out of the gate (decent performance, predictability, and security)
You forgot the link. :)
http://yehudakatz.com/2016/10/11/im-excited-to-work-on-yarn-...
Re: Yarn – A new package manager for JavaScript
#39I wrote a post explaining why I'm psyched to be working on it: TLDR: - open, community governance that will support long-term evolution - the technical details get a lot right out of the gate (decent performance, predictability, and security)
Have you guys approached the ridiculous folder nesting situation? E.g. breaking out of the current/broken node_modules structure?
There has been no problems with folder nesting in `npm` in general since the version@3 came out over a year ago.
Re: Yarn – A new package manager for JavaScript
#40"The React Native package.json currently lists just 68 dependencies, but after running npm install the node_modules directory contains 121,358 files."
That, to me, is what is wrong with npm. The problem stems from node.js not coming with "batteries included" so there is a proliferation of tiny libraries that do the most trivial things.