Yarn's Future – v2 and beyond • Hacker News Board

Re: Yarn's Future – v2 and beyond

#211

Post by shados » Fri, Jan 25, 2019, 12:18 AM UTC

DuskStar wrote: post #169

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.

I think if you're merging lockfile diffs, you're doing something wrong! Merge the package.json diffs and regenerate the lockfile.

If you're regenerating lock files, you're losing all your locks for the stuff that didn't change, which can lead to unpredictable bugs.

Fortunately as someone else replied, both yarn and npm have safe and easy ways to resolve merge conflicts in their lock files.

Re: Yarn's Future – v2 and beyond

#212

Post by Aeolun » Fri, Jan 25, 2019, 12:37 AM UTC

h1d wrote: post #11

Aeolun wrote: post #7

I’m glad that Yarn will continue. Npm has improved, but it’s still less pleasant to work with than yarn (which basically always does what I expect, not so for npm).

Which part of npm acts unexpectedly?

One thing that comes to mind is the lockfile not actually acting as a lockfile.

Running ‘npm install’ updates the lockfile :/

Then there was the issue where it didn’t respect git commit hashes that were added to the lockfile, just taking whatever the latest commit was.

Re: Yarn's Future – v2 and beyond

#213

Post by int_19h » Fri, Jan 25, 2019, 1:19 AM UTC

cphoover wrote: post #176

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…

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.

Re: Yarn's Future – v2 and beyond

#214

Post by exogen » Fri, Jan 25, 2019, 1:21 AM UTC

nevir wrote: post #66

Aeolun wrote: post #7

I’m glad that Yarn will continue. Npm has improved, but it’s still less pleasant to work with than yarn (which basically always does what I expect, not so for npm).

npm has eroded so much of my trust that I am hesitant to switch back to it any time soon. I've tried npm out every few months (since npm 3), and have consistently run into infuriating bugs or unexpected behaviors. Much of it has been fixed over time, but the frequency and duration of these issues is concerning—and, I think, points to architectural deficiencies being the root of the problem. (And the project is so mas…

Even the latest version of npm 6 can get dependency resolution wrong. Like, the basic core feature.

Re: Yarn's Future – v2 and beyond

#215

Post by int_19h » Fri, Jan 25, 2019, 1:22 AM UTC

CGamesPlay wrote: post #16

> The log system will be overhauled - one thing in particular we'll take from Typescript are diagnostic error codes. Each error, warning, and sometimes notice will be given a unique code that will be documented - with explanations to help you understand how to unblock yourself. Why do programmers love error codes? As an end user, they are useless indirection to me and the only way this would even be tolerable is if t…

To add to the other replies - you quickly find the utility of error codes when working on a product that ships in many different languages. Diagnosing a bug report from, say, a Chinese user can be a lot easier if the screenshot with the error message also has the code in it somewhere.

Re: Yarn's Future – v2 and beyond

#216

Post by exogen » Fri, Jan 25, 2019, 1:23 AM UTC

arcatek wrote: post #194

exogen wrote: post #165

Earlier quoted context omitted.

I'm assuming that lifecycle scripts (and scripts called by lifecycle scripts) in particular will still need to use common Windows-supported syntax? Even if the devs of the package are guaranteed to be using Yarn, people installing the package might still be using npm. So I assume some caveats apply to some scripts, right? p.s. I love Yarn :)

The `postinstall` scripts would likely be better off without using those features, indeed. But in the end, your packages would be better off without `postinstall` scripts anyway ;)

Yeah I don't recommend `postinstall`, but `prepare` (and all the potential build-type scripts it could run) is actually useful (esp. for allowing people to install from unpublished versions via git), and would need special consideration. :(

Re: Yarn's Future – v2 and beyond

#217

Post by Klathmon » Fri, Jan 25, 2019, 1:24 AM UTC

scrollaway wrote: post #23

CGamesPlay wrote: post #16

> The log system will be overhauled - one thing in particular we'll take from Typescript are diagnostic error codes. Each error, warning, and sometimes notice will be given a unique code that will be documented - with explanations to help you understand how to unblock yourself. Why do programmers love error codes? As an end user, they are useless indirection to me and the only way this would even be tolerable is if t…

Error codes are googlable. Things like "TS1234", "flake8 E802", "Yarn E4882" etc are pretty much guaranteed to give you the results you want. Whereas "yarn some-error-text" can be much noisier, especially if the error text changes over time, is short, is obscure or even translated. Worst case they're also more greppable inside the codebase. Error codes are a really, really good idea if your application is popular and…

> if your application is popular and used by devs

I'd argue even if it's not popular and it's used by non-devs.

Error codes saved our support people a ton of time when trying to understand user problems. It's good for the user to be able to understand the problem, but it's great when they can call you up or send a ticket in about error "E4882", and you instantly have a good amount of information about the problem.

Re: Yarn's Future – v2 and beyond

#218

Post by int_19h » Fri, Jan 25, 2019, 1:24 AM UTC

linkmotif wrote: post #137

wanted2 wrote: post #128

Earlier quoted context omitted.

> , and to everyone's benefit. Why? I've worked on large codebases in Coffeescript, ES6 and Typescript. Whatever this whole community sings and believes, but Coffeescript still wins for me. ES6 is still trying to catch up but will probably never reach the beauty and ease of Coffeescript. Both are transpilers, only ES6 with Babel is a total horror to manage (just upgraded a large codebase to Babel 7..). Typescript tak…

> Show me a Typescript codebase not using the type 'any'! Show me a Java project without an unchecked cast... I’m not a CS person but my impression is that sometimes you need these types and they exist in the type system for a reason. No type system is conceptually “perfect” as in there are soundness/expressively tradeoffs. I don’t think using ‘any’ is always bad. Sometimes it’s even right?

There are type systems that don't have anything like "any" - you find that in languages like OCaml or Haskell.

But in TS, the main reason for "any" is interop with JS.

Re: Yarn's Future – v2 and beyond

#219

Post by int_19h » Fri, Jan 25, 2019, 1:29 AM UTC

LaGrange wrote: post #188

kimsk112 wrote: post #33

Earlier quoted context omitted.

I recalled when Microsoft employees and MVPs denied when Silverlight was dying. :-( I think the TypeScript momentum is too strong now.

I think Flow's in more direct trouble, but I wouldn't announce victory for TypeScript just yet. With wasm around the corner, things may (or may not, shrug ) change significantly.

Even with wasm, much as I'm looking forward to the Great JS Purge personally, it's not going to happen anytime soon - too much existing code and devices. JS will remain necessary on the front-end for at least another decade, and probably beyond that. So TS will still be necessary to make the pill less bitter.

Re: Yarn's Future – v2 and beyond

#220

Post by linkmotif » Fri, Jan 25, 2019, 1:45 AM UTC

int_19h wrote: post #218

linkmotif wrote: post #137

Earlier quoted context omitted.

> Show me a Typescript codebase not using the type 'any'! Show me a Java project without an unchecked cast... I’m not a CS person but my impression is that sometimes you need these types and they exist in the type system for a reason. No type system is conceptually “perfect” as in there are soundness/expressively tradeoffs. I don’t think using ‘any’ is always bad. Sometimes it’s even right?

There are type systems that don't have anything like "any" - you find that in languages like OCaml or Haskell. But in TS, the main reason for "any" is interop with JS.

Thanks. So in OCaml/Haskell you can write perfectly sound programs?