Clashes with Apache YARN - https://hadoop.apache.org/docs/r2.7.2/hadoop-yarn/hadoop-yar...
They are different problem domains, I think confusing them is unlikely
Yarn – A new package manager for JavaScript
111–120 of 486 posts
Re: Yarn – A new package manager for JavaScript
#112My initial tests with this are very positive (I tried this use case here: https://github.com/npm/npm/issues/10999 ). It handled it quite well and we'll definitely be considering this for our package. I'm curious about the "flattening" approach though -- and why something like ied ( https://github.com/alexanderGugel/ied ) wasn't done instead. ied only ever installs one copy of a module, but allows each module to think…
Hey! I'm Sebastian McKenzie (@kittens on GitHub) and I'm the lead develop on Yarn at Facebook. We initially used a method similar to ied when we first started experimenting with internal usage at Facebook.
We ran into a lot of issues with OS compatibility around symlinks and existing tools not supporting it. Windows lacks support for symlinks on non-Admin accounts, NTFS junctions work but they're slightly quirky in their behaviour and don't behave exactly the same way.
A lot of tooling relies on the existing node_modules structure. ESLint for example will load tools relative to itself which means that they need to be reachable in the tree, you can solve this with hardlinks but there's caveats with that too. Existing tools aren't very well suited for handling cycles either which in a system like npm are extremely common as a transitive module could depend on one that's higher in the graph.
We care a lot about existing ecosystem compatibility and because of these limitations we went with the current status quo. We'll continue to explore others options though and if there's a chance we can do it without any of these caveats then we're more than happy to explore it.
Let me know if you have any further questions!
Re: Yarn – A new package manager for JavaScript
#113Earlier quoted context omitted.
> This also highlights a shrewd move on the part of npm: a clear decoupling between the npm registry and client, with a well-defined protocol between the two. The strength of Node is in the staggering size of its ecosystem; how those bits end up on disk is an implementation detail. This smart separation allows for this kind of experimentation on the client side, without causing the ecosystem fragmentation that happen…
> Yarn pulls packages from registry.yarnpkg.com, which allows them to run experiments with the Yarn client. This is a proxy that pulls packages from the official npm registry, much like npmjs.cf.[0] Time will tell whether they only want to be proxying NPM or will allow direct pushing to their own registry. If they do, JS ecosystem might see another big shift. [0] http://blog.npmjs.org/post/151660845210/hello-yarn
[deleted]
Re: Yarn – A new package manager for JavaScript
#114This looks awesome. But I have to wonder why create a whole new project rather than fork or upstream these changes to NPM? It doesn't seem like it's doing anything fundamentally different or outside of NPM's scope of responsibility.
Because the npm client is a hot mess?
The official npm cli is quite old and evolved along with all the different coding styles and architecture choices of the node and JS ecosystems.
It's also full of dependencies on originally purpose-built modules that suffer from the same problems. This compounds various issues, resulting in long-standing bugs like `npm publish` sometimes not actually including all files in the tar bundle it generates[0].
NPM 3 was a partial rewrite but it's still built on the same mountain of code as NPM 2 and 1. npm Inc developers have in the past complained about not being able to address issues for a lack of resources despite having a ton of developers on the team[1].
The official npm client also doubles as an account management CLI to the npm registry. Which apparently npm Inc now considers a design flaw as they recently started creating a standalone tool for managing other aspects of their commercial services[2].
And finally it's important to understand that having a new package manager that is not tied into npm Inc means it's easier to replace the npm registry as the official node module registry in the future. Which would allow the community to get rid of the privileged position npm Inc currently holds in the node distribution (which is otherwise governed by the Node Foundation).
Rewriting the client from scratch actually turned out to be the sanest approach in this situation, I think.
[0]: https://github.com/npm/npm/issues/5082
Re: Yarn – A new package manager for JavaScript
#115My initial tests with this are very positive (I tried this use case here: https://github.com/npm/npm/issues/10999 ). It handled it quite well and we'll definitely be considering this for our package. I'm curious about the "flattening" approach though -- and why something like ied ( https://github.com/alexanderGugel/ied ) wasn't done instead. ied only ever installs one copy of a module, but allows each module to think…
Hey! I'm Sebastian McKenzie (@kittens on GitHub) and I'm the lead develop on Yarn at Facebook. We initially used a method similar to ied when we first started experimenting with internal usage at Facebook. We ran into a lot of issues with OS compatibility around symlinks and existing tools not supporting it. Windows lacks support for symlinks on non-Admin accounts, NTFS junctions work but they're slightly quirky in t…
As Sebastian said we are more than excited to explore what we can improve in the future. If you are interested, please start a discussion on the GitHub issue tracker: https://github.com/yarnpkg/yarn :)
Re: Yarn – A new package manager for JavaScript
#116> Finally, updating a single dependency with npm also updates many unrelated ones based on semantic versioning rules. This makes every change much larger than anticipated, and having to do things like committing node_modules or uploading it to a CDN made the process less than ideal for engineers. You shouldn't check in node_modules. You should use a shrinkwrap file to indicating the specific sub-dependency versions y…
They address pretty throroughly why that does not work for them in the linked article.
> They address pretty throroughly why that does not work for them in the linked article.
Not really. They just mention it in passing:
From the article
>> Shrinkwrap files aren't generated by default and will fall out of sync if engineers forget to generate them, so we wrote a tool to verify that the contents of the shrinkwrap file matches what's in node_modules. These files are huge JSON blobs with unsorted keys, though, so changes to them would generate massive, difficult-to-review commits. To mitigate this, we needed to add an additional script to sort all the entries.
Comparing node_modules to shrinkwrap isn't necessary. Building the app will re-generate node_modules and tests should catch whether or not the app works as intended.
The sorting issue for shrinkwrap is legit, but the answer to that is sort it! Sure you'll get some deep diffs if the dependencies change, but that reflects the real changes to the app.
The simpler answer seems to be to add a build test to mandate the existence of a shrinkwrap file, verify it's sorted, and (optionally) verify it's up to date. The latter doesn't even have to be done every build.
Re: Yarn – A new package manager for JavaScript
#117Re: Yarn – A new package manager for JavaScript
#118There's a lot to like here - deterministic builds are great. However, yarn doesn't currently seem to support installing straight from github or private packages [0], [1].
I'm sure this will be added in the future, but it is currently a dealbreaker for me - I'm using a single package that's just straight hosted in a private git repo, as the package itself isn't ready to be published yet. I'm sure other people are using private packages for more normal reasons (closed source, pre-production, etc).
If yarn actually made it simpler to refer to a local package during development, I'd be on board with that. (I am developing the dependency, but want to also work on the thing that depends on it, so I'd rather just save locally and refresh npm on the outer project, but that's hard to get right - file urls don't always update, the easiest workflow seems to be delete the package from node_modules, and npm install, with the package having a git url rather than a version in package.json).
Re: Yarn – A new package manager for JavaScript
#119Should you commit the yarn lockfile to version control?
Docs here [1] say yes.
It also seems to imply that this is edited by the `yarn` command so it would be invalidated if you manually edited your `package.json`? Dunno if it's destructively invalid though.
1: https://yarnpkg.com/en/docs/configuration#toc-use-yarn-lock-...
Re: Yarn – A new package manager for JavaScript
#120yarn.lock[0] is similar to composer.lock[1]
[0] https://github.com/yarnpkg/yarn/blob/99dd4504469273332f01ce5... [1] https://github.com/composer/composer/blob/20ee689bb464edfe7e...