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

Yarn's Future – v2 and beyond

github.com

Post reply on HN
Print view View original

231–239 of 239 posts

Re: Yarn's Future – v2 and beyond

#231

Post by mhd »

chaostheory wrote: post #159
mhd wrote: post #118

Earlier quoted context omitted.

I'd prefer Eiffel or Oberon, but almost anything is better than ES6. I just wish there was some kind of standard library movement to coincide with it, but even MS seems okay with left-pad.

> I just wish there was some kind of standard library movement to coincide with it, I keep hearing this complaint, and at the same time I'm wondering why it's a big problem. So you can't find 3rd party libraries that are good enough to fill in the void from the lack of a good standard library?

Yes, pretty much. I don’t want to bikeshed elementary parts of the developer experience, never mind vetting all the teeny components or find replacements if dependency hell strikes, quality regresses or maintainers disappear.

Given all the constraints, it’s highly unlikely that you find something consistent.

Re: Yarn's Future – v2 and beyond

#232

Post by mhd »

RobertKerans wrote: post #183
mhd wrote: post #118

Earlier quoted context omitted.

I'd prefer Eiffel or Oberon, but almost anything is better than ES6. I just wish there was some kind of standard library movement to coincide with it, but even MS seems okay with left-pad.

> even MS seems okay with left-pad That's a strange choice of example to highlight the sparseness of the standard library.

I thought it's a good illustration of how fractured and fragile the JS "library" situation is. It's a bit like the previous PHP standard library, combined with the worst of Perl's Tim Toady.

Re: Yarn's Future – v2 and beyond

#233

Post by Vinnl »

drodgers wrote: post #168
donatj wrote: post #144

Earlier quoted context omitted.

I'd say safely merging YAML diffs however could be trouble. I don't know how restricted their YAML subset is, but in my experience it's so loose a format the only way to be sure YAML says what you think it says is to run it through a parser.

> safely merging YAML diffs however could be trouble Yarn will actually do the merging automatically — if you have conflict markers in your lockfile, just running yarn will parse them along with the rest of the file and produce a new lockfile with the changes from both diffs (unless there's a genuine conflict). I assume that this feature won't go away with the new lockfile format

I hope so, but that feature wasn't there from the start: https://github.com/yarnpkg/yarn/pull/3544

Hopefully they'll be able to re-use much of that work for the Yaml file.

Re: Yarn's Future – v2 and beyond

#234

Post by Vinnl »

donatj wrote: post #144
wopian wrote: post #67

Earlier quoted context omitted.

npm's lockfile is a pain to diff in PRs because of the JSON format where what was maybe 20 changed lines in yarn is upwards of 80 from the brackets. With YAML and whatever format yarn.lock was in, the only changed lines are changes to the version resolutions, hash and dependencies.

I'd say safely merging YAML diffs however could be trouble. I don't know how restricted their YAML subset is, but in my experience it's so loose a format the only way to be sure YAML says what you think it says is to run it through a parser.

They do say "subset of YAML", so presumably that can make it easier. And hopefully they'll keep handling this for you.

Re: Yarn's Future – v2 and beyond

#235

Post by Waterluvian »

s_tec wrote: post #206
Waterluvian wrote: post #184

Earlier quoted context omitted.

I agree with your sentiment but I find the location of it almost ironic. One thing I hate is when I go into a language and it's full of, "oh don't use the built-in, use this thing over here...". If we want a clear winner to everyone's benefit, wouldn't we want Yarn to go away and for npm to gain whatever it's missing that makes Yarn relevant? To be fair, I haven't touched Yarn in years. I switched to it, loved it, an…

I get what you are saying, but the two cases are different. Typescript is a whole different language from Flow, so they can't interoperate. Every package that migrates to Typescript deprives the Flow ecosystem of compatibility and mindshare, so a win for one is always a loss for the other. Nobody wants to be a loser, so this will eventually resolve itself into a single dominant choice. NPM and Yarn don't have this pr…

That's a really good point. Thanks for sharing. Drop in alternatives can be healthy and not that harmful. It's not like we are locked into two separate camps.

Re: Yarn's Future – v2 and beyond

#236

Post by zbentley »

wopian wrote: post #67
scrollaway wrote: post #38

Very happy to see yarn.lock will finally be a proper format that won't need its own parser. YAML subset is a pretty good choice, though I think canonicalized, indented JSON would be a better choice for this use case. Incidentally that's what npm uses as lockfile, I wonder if there's room to have the two package managers share the format (or even share the file itself). Very excited to see shell compatibility guarante…

npm's lockfile is a pain to diff in PRs because of the JSON format where what was maybe 20 changed lines in yarn is upwards of 80 from the brackets. With YAML and whatever format yarn.lock was in, the only changed lines are changes to the version resolutions, hash and dependencies.

Diffability is not a great argument against YAML/for JSON IMO. Tools can usually handle that for you.

What is the largest concern about YAML is that truncated documents are almost always still valid documents. The likelihood of that happening compared to, say, a git merge gone wrong is much lower, but the consequences are likely much worse.

I don't have a strong opinion on structured data file format, but that's an issue with YAML that often goes unmentioned.

Re: Yarn's Future – v2 and beyond

#237

Post by ergothus »

int_19h wrote: post #213
cphoover wrote: post #176

Earlier quoted context omitted.

Nah YAML is better because of diffing. JSON uses commas `,` which will show multiple changes when the last item of a list changes.

Side note: it's really sad that more languages aren't allowing trailing commas in sequence literals and other places, like Python does. In Python, these are legal: [1, 2, 3,] foo(1, 2, 3,) And thus, when writing multiline literals and calls, it's pretty common to use the comma as a line terminator , precisely so that new lines can be added at the end without touching the previous line.

Javascript DOES allow trailing commas, though it never caught on since IE6 would blow up on them.

JSON, however, does not.

Re: Yarn's Future – v2 and beyond

#238

Post by RobertKerans »

mhd wrote: post #232
RobertKerans wrote: post #183

Earlier quoted context omitted.

> even MS seems okay with left-pad That's a strange choice of example to highlight the sparseness of the standard library.

I thought it's a good illustration of how fractured and fragile the JS "library" situation is. It's a bit like the previous PHP standard library, combined with the worst of Perl's Tim Toady.

The reason I say it's a strange example is because of this: https://github.com/tc39/proposal-string-pad-start-end, which was added to the language two years ago (and seemingly very quickly [as tc39 proposals go], I assume due to left-pad)

Re: Yarn's Future – v2 and beyond

#239

Post by chaostheory »

mhd wrote: post #231
chaostheory wrote: post #159

Earlier quoted context omitted.

> I just wish there was some kind of standard library movement to coincide with it, I keep hearing this complaint, and at the same time I'm wondering why it's a big problem. So you can't find 3rd party libraries that are good enough to fill in the void from the lack of a good standard library?

Yes, pretty much. I don’t want to bikeshed elementary parts of the developer experience, never mind vetting all the teeny components or find replacements if dependency hell strikes, quality regresses or maintainers disappear. Given all the constraints, it’s highly unlikely that you find something consistent.

So you write your own standard library substitutes? Math, functional, etc...?
Post reply on HN