Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Yarn – A new package manager for JavaScript

code.facebook.com

Post reply on HN
Print view View original

261–270 of 486 posts

Re: Yarn – A new package manager for JavaScript

#261

Post by Ajedi32 »

wycats wrote: post #237
_greim_ wrote: post #174

Earlier quoted context omitted.

> Multiple versions [...] almost always a bad idea If so, different major versions of the same dep should be considered different libraries, for the sake of flattening. Consider lodash for example.

That's exactly what Cargo does, but it also takes a further step of making `^` the default operator and strongly discouraging version ranges other than "semver compatible" post-1.0.

Looks like Yarn does something similar: https://yarnpkg.com/en/docs/cli/add#toc-yarn-add-exact

Personally I'm not really sure I like it. If I specify an exact revision of something, chances are I really do mean to install that exact revision. I don't see why I need an extra flag for that.

Re: Yarn – A new package manager for JavaScript

#262

Post by ksherlock »

Kenan wrote: post #239
ksherlock wrote: post #69

Earlier quoted context omitted.

It's improved but it's not fixed. if a depends on c 1.0 and b depend on c 2.0, both versions of c need to be installed and one of them will be nested.

What's the solution for that case though (one which requires no nesting)? I don't think a solution with no nesting exists given the current module resolution algorithm of Node.js, which allows for only a single version of a particular package to exist at a given level.

nesting can't be prevented in that case (at least with the current node require() design). It gets really bad if you have 10 packages that depend on c@1.0.0 and 10 packages that depend on c@2.0.0 -- one of them will install in the root directory and the other 10 will be duplicated. ied stores a single copy of each package@version and uses symlinks which is an improvement. Apparently yarn tried something similar but it breaks some packages (that check where they're located for example).

https://github.com/alexanderGugel/ied

Re: Yarn – A new package manager for JavaScript

#263

Post by losvedir »

Very interesting! How does the lockfile work with optional dependencies? We've run into this issue[0] on npm with a bad interaction between optional dependencies and the shrinkwrap. We develop on OS X and our CI server is linux, and fsevents works on one but not the other.

[0] https://github.com/npm/npm/issues/2679

Re: Yarn – A new package manager for JavaScript

#265

Post by Osiris »

bandrami wrote: post #246
fuzzy2 wrote: post #184

Earlier quoted context omitted.

You say tooling, but then talk about libraries. I think both are just as numerous for nearly all popular programming languages. It’s just that JavaScript is currently “hot shit”, so all this stuff is a lot more visible. There are tons of libraries for C, many of which aim to do the same, only faster/smaller/scalable/whatever. There are many compilers, both open and closed source. And there are documentation tools, sy…

You say tooling, but then talk about libraries. Because, from this outsider's perspective, it seems like most of the tooling is library management (rather than, say, profiling or linting -- does javascript even have a linter? -- or debugging).

> does javascript even have a linter? -- or debugging

Yes, as libraries. There are multiple linter options that can be installed with a project. Debugging is available, usually through an IDE or browser.

Re: Yarn – A new package manager for JavaScript

#267

Post by dismantlethesun »

spankalee wrote: post #62

Yarn is particularly great for front-end web apps because of its flat installation mode. ES6 module imports and HTML Imports both require that dependencies are imported by URL. This means that the only reliable way to import another module is by relative URL, like: import * as $ from '../jquery/jquery.js'; This requires that packages are installed flat, as siblings. Yarn is going to enable native JS modules and proje…

You can use webpack or JSPM to resolve directories at the top level. That way you can just import "web/X" even if the web/ directory isn't a sibling to your current file.

It's not very helpful if you are distributing an NPM package, but for people who aren't authoring libraries, its a godsend.

Re: Yarn – A new package manager for JavaScript

#268

Post by spankalee »

dismantlethesun wrote: post #267
spankalee wrote: post #62

Yarn is particularly great for front-end web apps because of its flat installation mode. ES6 module imports and HTML Imports both require that dependencies are imported by URL. This means that the only reliable way to import another module is by relative URL, like: import * as $ from '../jquery/jquery.js'; This requires that packages are installed flat, as siblings. Yarn is going to enable native JS modules and proje…

You can use webpack or JSPM to resolve directories at the top level. That way you can just import "web/X" even if the web/ directory isn't a sibling to your current file. It's not very helpful if you are distributing an NPM package, but for people who aren't authoring libraries, its a godsend.

Do you mean import '/web/X'? Import URLs have to start with a `/`, `./`, or `//`.

Even so, that requires a build tool. I want to be able to load working sources directly out of my packages directory.

Re: Yarn – A new package manager for JavaScript

#269

Post by spankalee »

MatthewPhillips wrote: post #163
spankalee wrote: post #62

Yarn is particularly great for front-end web apps because of its flat installation mode. ES6 module imports and HTML Imports both require that dependencies are imported by URL. This means that the only reliable way to import another module is by relative URL, like: import * as $ from '../jquery/jquery.js'; This requires that packages are installed flat, as siblings. Yarn is going to enable native JS modules and proje…

This is what I was most curious about, but it looks like --flat is a cli option but not the default. Definitely moving in the right direction though!

--flat is the cli option, but there's also "flat": true support in package.json. Used at the top level this forces a flat install, but used in a dependency it means that that package requires a flat install and it throws an error if it's not.

This means that HTML imports and ES6 modules can force flat installs and start moving the front-end package ecosystem in that direction.

Re: Yarn – A new package manager for JavaScript

#270

Post by jakub_g »

_ea1k wrote: post #258
rubber_duck wrote: post #148

Earlier quoted context omitted.

The fun of kicking off a CI build after the weekend with no commits and see stuff randomly break because some dependency of a dependency got updated and broke things in a minor version is something I've only experienced in JS - beautiful.

In fairness to the language and tools, this seems to be more of a cultural problem than anything. You can do the same kind of version range tricks in typical Java builds, for example (Maven), but most people hardcode the values to keep builds as deterministic as possible. For some reason, the JS community seems to prefer just trusting that new versions won't break anything. Its either very brave of them really (or ma…

I hate non-reproducible builds and semver-relaxed dep-of-the-dep issues, but, while a broken dep fails the build for lots of people (downside), the upside of this is that very quickly (within hours of a new dep being published) there will be lots angry people complaining about it on GitHub, and a faulty dep will be typically quickly rolled back / superseded with a patch. Otherwise, some bugs might be sitting hidden for a long time.
Post reply on HN