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

Re: Yarn's Future – v2 and beyond

#21

Post by lost_my_pwd » Thu, Jan 24, 2019, 4:13 PM 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…

Humans are not always the consumer of error output. Distinct error codes simplify parsing and eliminate ambiguity.

It also makes it easier for developers look up a specific error in the documentation, assuming it's been documented.

Re: Yarn's Future – v2 and beyond

#22

Post by acemarke » Thu, Jan 24, 2019, 4:13 PM UTC

russley wrote: post #6

sebazzz wrote: post #3

There appears to be a real movement to move from Flow to typescript. Is Flow dying?

There have been several projects that were flow based that have moved to TS. I think the real litmus test will be if React eventually either includes TS types or is rewritten in TS. Disclaimer: I work with TypeScript professionally.

I'm pretty in tune with what's going on around React, and I don't see that one ever happening.

The React team is _very_ busy already with work around Hooks, Concurrent Mode, and Suspense. There's no way they're going to pause development on implementing all these major chunks of functionality just to rewrite from one type system to another.

I've seen Dan express some frustration with Flow's pace of development on Twitter a couple times, but beyond that, no indications whatsoever that React would be converted to TS. In the entirely hypothetical scenario that React _did_ get rewritten to another language, I have to assume it would be something like ReasonML (which was created by Jordan Walke, the original creator of React).

Re: Yarn's Future – v2 and beyond

#23

Post by scrollaway » Thu, Jan 24, 2019, 4:14 PM 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…

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 used by devs, IMO.

Re: Yarn's Future – v2 and beyond

#24

Post by ben_jones » Thu, Jan 24, 2019, 4:15 PM 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…

IMO Error codes are easier to search then english error descriptions.

Re: Yarn's Future – v2 and beyond

#25

Post by coding123 » Thu, Jan 24, 2019, 4:15 PM 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?

We switched around June last year to yarn because git URL dependencies on branches was broken in npm. It would choose incorrect commit ids inexplicably. Beyond that dependency upgrade time is faster.

Re: Yarn's Future – v2 and beyond

#26

Post by treis » Thu, Jan 24, 2019, 4:15 PM 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…

That's exactly the point. The unique error code matches up with documentation so you can easily research your problem. Especially helpful with Google. Yarn "some error happened" is a lot more difficult to track down than Yarn "Error 3617" even if Error 3617 doesn't immediately provide more information.

Re: Yarn's Future – v2 and beyond

#27

Post by mydpy » Thu, Jan 24, 2019, 4:16 PM UTC

For the uninitiated / confused, this refers to yarnpkg, the JavaScript dependency manager, not (Hadoop) YARN, the cluster manager.

Re: Yarn's Future – v2 and beyond

#28

Post by lachenmayer » Thu, Jan 24, 2019, 4:17 PM 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…

The Rust compiler generates unique error codes for every type of error, and suggests that you run the command `rustc --explain E0275` (as an example) to get more information on the error, with an (often) in-depth description of what the error means, how it is usually caused, how to potentially fix it, etc.

This is extremely useful, because the error output can focus on just saying what the error is (which is great when you already know what the error means), and there is an obvious next step to get more information if you need more help.

And if you don't find the answer, searching online for "rust E0275" gives much more relevant answers than trying to search the right parts of the error message.

Re: Yarn's Future – v2 and beyond

#29

Post by dmix » Thu, Jan 24, 2019, 4:17 PM UTC

lost_my_pwd wrote: post #21

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…

Humans are not always the consumer of error output. Distinct error codes simplify parsing and eliminate ambiguity. It also makes it easier for developers look up a specific error in the documentation, assuming it's been documented.

It's also easier for a (technical) user to reference they got error 1018 than copy & paste "An index signature parameter cannot have an accessibility modifier." Especially in titles and when referencing it multiple times within a body of text.

Re: Yarn's Future – v2 and beyond

#30

Post by lmm » Thu, Jan 24, 2019, 4:18 PM UTC

mrspeaker wrote: post #12

sebazzz wrote: post #3

There appears to be a real movement to move from Flow to typescript. Is Flow dying?

Does anyone know of any "third choice" around typing JavaScript? I would love to add types to my code, but I want to write "real" JavaScript: so the code I input is the code that is executed by the browser. I just want the compile step to strip away the type annotations. There was initially talk of Flow using comments to actually work without touching the source code at all, but I don't think anything came of that...…

If you're using Babel for compatibility with particular browsers then that can already handle TypeScript. What distinction are you drawing between a compile step that "strips away the type annotations" and one that does something else - what else is it that you consider compiling TypeScript to include?

I have to ask what you're trying to achieve here. Moving types into comments just gives people who build without your typechecker the chance to break your code.