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

31–40 of 239 posts

Re: Yarn's Future – v2 and beyond

#31

Post by masklinn »

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…

As far as Rust is concerned[0] the error code is accompanied by a pretty extensive error message (with lots of arrows and suggestions) but the actual error code documentation is basically an entire book page, it would be completely unusable if that much stuff were printed to the terminal. So the compilation error provides an explanation and the error code links to an expanded explanation.

For instance, this is the basic "use after drop" error message:

    error[E0382]: borrow of moved value: `s`
     --> src/main.rs:5:20
      |
    4 |     drop(s);
      |          - value moved here
    5 |     println!("{}", s);
      |                    ^ value borrowed here after move
      |
      = note: move occurs because `s` has type `std::string::String`, which does not implement the `Copy` trait
this is the expanded explanation: https://doc.rust-lang.org/stable/error-index.html#E0382 On my machine, I have to "page down" twice to get through the entire thing. "rustc --explain E0382 | wc" tells me the markdown source is close to 110 lines and 550 words.

And as other people noted, hopefully other folks discussing the issue used the error code, which makes their discussion not just more easy to find but survive localisation: if you get a localised error message it's almost impossible to find information on it unless it's absolutely ubiquitous, because the vast majority of the discussions (and especially the most useful discussions) are going to refer to the non-localised version, which your software will not provide.

edit: I can understand taking issue with it though, some systems do use error codes to skimp on the actual error messages. I recall Oracle being a particularly bad offender.

[0] I'd expect Typescript is the same, but don't know for sure

Re: Yarn's Future – v2 and beyond

#33

Post by kimsk112 »

LaGrange wrote: post #9
sebazzz wrote: post #3

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

Facebook (excuse me, bunch of FB employees from the Flow team) says no: https://github.com/facebook/flow/issues/7365#issuecomment-45... . Of course, that's exactly what I'd say if I was in charge of a dying project. Edit: but, their main codebase is in Flow, and that sounds like a mess to migrate, so I wouldn't be _too_ worried. It might slow down, but I doubt it will become unmaintained anytime before Facebook gets…

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

Re: Yarn's Future – v2 and beyond

#34

Post by talltimtom »

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.

How does an error code make it easier to look up an error? The workflow is either “get error, google it”, or “get errorcode google it”. In both cases the docs will be the top hit.

If we where talking 20 years ago I might agree, but I really can’t see the argument with todays tooling.

Re: Yarn's Future – v2 and beyond

#35

Post by z3t4 »

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…

Many scripts rely on the error's in order to decide what to do. When you have error codes, you can then change the actual description of the error without breaking the scripts that rely on the error codes. You can also show the errors in different languages depending on the user's settings.

Re: Yarn's Future – v2 and beyond

#36

Post by dhritzkiv »

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?

Not that this is a showstopper, but I have issues with the package-lock.json file where the `resolved` field (the package's registry URL) constantly flip flops between http and https protocols, depending on which machine I'm on (home, work, or docker container), whenever I run `npm install`. Sounds not so bad, but it becomes a mess in git, and causes any docker build caches to become invalidated.

Re: Yarn's Future – v2 and beyond

#37

Post by janpot »

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?

Recently bumped into https://npm.community/t/packages-with-peerdependencies-are-i... The attitude towards fixing issues ("we won’t be able to fix until we get through an upcoming tree builder rewrite.", yeah right...) is making me want to check out alternatives

Re: Yarn's Future – v2 and beyond

#38

Post by scrollaway »

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 guarantee in scripts as well. Using environment variables in scripts is a pain right now.

Finally one of the biggest news is the switch from Flow to Typescript. I think it's now clear that Facebook is admitting defeat with Flow; it brought a lot of good in the scene but Typescript is a lot more popular and gets overall much better support. Uniting the JS ecosystem around Typescript will be such a big deal.

Re: Yarn's Future – v2 and beyond

#39

Post by kylestlb »

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…

You can also ask "why do programmers love GUIDs" and probably receive a similar response.

The HTTP protocol is another famous example of user-facing error/status codes that don't necessarily mean anything on their own.

Re: Yarn's Future – v2 and beyond

#40

Post by [deleted] »

_hardwaregeek wrote: post #17
mrspeaker wrote: post #12

Earlier quoted context omitted.

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...…

TypeScript works with JSDoc annotations: https://github.com/Microsoft/TypeScript/wiki/JsDoc-support-i...

[deleted]
Post reply on HN