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

41–50 of 239 posts

Re: Yarn's Future – v2 and beyond

#41

Post by scrollaway »

dhritzkiv wrote: post #36
h1d wrote: post #11

Earlier quoted context omitted.

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.

That sounds pretty bad and I'm not so sure it's a npm bug. Do you have a diff of the change in question? Is it on the npm registry or a custom one?

Re: Yarn's Future – v2 and beyond

#42

Post by noir_lord »

ng12 wrote: post #15
sebazzz wrote: post #3

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

Flow really shines when you have a large, untyped codebase and want to incrementally add types to it. If you're starting a new project (or rewriting one) TypeScript is the more sensible choice. By nature Flow is going to be used less and less over time.

For people now thinking well we have a large untyped codebase..damn.

You can turn typescripts type inference on on a regular js file.

https://www.typescriptlang.org/docs/handbook/type-checking-j...

Re: Yarn's Future – v2 and beyond

#43

Post by agentultra »

sebazzz wrote: post #3

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

I'm curious as to this trend as well. I've read the justifications for it in each case and in this particular one I don't get it.

Isn't Flow more concerned with soundness than intellisense? Has TypeScript caught up with Flow in this regard?

Perhaps it's because I prefer to do my work in strongly typed, pure FP languages where I can but I work professionally with JS and have been investing in Flow there for over a year now. While Flow is still not exactly great it can at least mimic exhaustive pattern matching and catches most unsafe type errors without getting in the way of common JS patterns too much.

The reason the yarn maintainers are giving is because they want more contributors? What advantage will that have if TypeScript isn't catching the errors you used to be able to catch or don't know about yet?

Curious to know if it's worth migrating over to TS without sacrificing anything other than the minor inconvenience.

Re: Yarn's Future – v2 and beyond

#44

Post by torben-friis »

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…

In general it improves interoperability between non-human systems.

Say that you have a database. When you ask it for a specific piece of data, and it can't find it, it shows 'data not found'.

Then I build a program that reads information from that database; I program it so that if it receives the text 'data not found' it knows to handle the error somehow.

Ten days later, the guy who programs the database decides that 'oops! we couldn't find the element :(' is a more friendly message to the user. Now my program will stop working until I switch it to the correct error text.

With an error code those kind of things don't happen. If you need extra legibility you can totally send both a code and a message, but the code is expected to remain unchanged and I can trust that it will stay the same in the future.

Grouping behaviours is another use. For example, if I have a system that sends you information and you have sent me wrong input, there's a dozen ways you could have done that (maybe you didn't send me enough data, or you sent it in chinese characters I don't recognise, or I just got gibberish I can't even start to understand). All of those cases might require different messages to the final user, but internally for me they're the same thing ('invalid data') and the things I'll have to do will be the same, so propagating a code serves me well.

There's also the issue of internationalization. If 200 android users across the world are having problems with their phones, and they all get an error 3242, they'll be able to find proper help. If one is showing "the application couldn't start due to memory issues", the other "la aplicacion no pudo iniciarse por problemas con la memoria" and yet another shows "لا يمكن بدء التطبيق بشكل صحيح" we're gonna have trouble identifying all those things as the same problem.

Re: Yarn's Future – v2 and beyond

#45

Post by mrspeaker »

lmm wrote: post #30
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...…

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

The comment stripping is optional (just for saving bytes on download). The goal is moving away from Babel, and any other unnecessary transpiling steps. Now that JavaScript has (a semi-working) module system, I find my projects having fewer and fewer dot files and far fewer dependencies.

If I can have a folder of plain JS that I know will work in a browser 20 years from now without having to resurrect an ancient/abandoned toolchain, then I'll do that!

Re: Yarn's Future – v2 and beyond

#46

Post by dhritzkiv »

scrollaway wrote: post #41
dhritzkiv wrote: post #36

Earlier quoted context omitted.

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.

That sounds pretty bad and I'm not so sure it's a npm bug. Do you have a diff of the change in question? Is it on the npm registry or a custom one?

It's on the npm registry, affecting the npm client: https://npm.community/t/some-packages-have-dist-tarball-as-h...

Re: Yarn's Future – v2 and beyond

#47

Post by aylmao »

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…

> I think it's now clear that Facebook is admitting defeat with Flow.

It sounds to me more like they're testing the waters. They're definitely opening up, with the whole Jest and create-react-app supporting it, but as far as using it themselves would this be the first project to be migrated?

Re: Yarn's Future – v2 and beyond

#48

Post by talkingtab »

I'm curious as to why yarn instead of contributing to NPM? I am aware that yarn was the inspiration for many improvements for NPM by providing an alternative, but going forward do we need two systems? Is the plan for yarn to be compatible with NPM and package.json?

Re: Yarn's Future – v2 and beyond

#49

Post by hiccuphippo »

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

I switched back to npm with version 5 and it's been great. Is there a list somewhere of feature parity between both?

Re: Yarn's Future – v2 and beyond

#50

Post by scrollaway »

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

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

That's what Typescript is. Type annotations don't change your code, they're stripped away by babel at compile time. In fact, by default, tsc does compile TS code which fails typechecking, into valid JS code (which will likely error when you use it at least in some circumstances, but can run just fine).

Typescript is a clear superset of JS, so there's no actual logical changes or even syntactical changes done by the compiler. However, you may be confused by the often-used "compilation target" features of babel (and tsc), which is that you may write ES2018 code, target ES5, and have your ES2018 syntactical sugar be turned into ES5-compatible code. This is entirely opt-in, and not related to typescript (other than the fact that Typescript is always compatible with the latest ES spec, so you can use any legal ES2018 syntax in it).

Hope that clears it up…

Post reply on HN