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

71–80 of 239 posts

Re: Yarn's Future – v2 and beyond

#71

Post by acemarke »

52-6F-62 wrote: post #62
acemarke wrote: post #22

Earlier quoted context omitted.

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

One of the benefits to TypeScript is that the codebase wouldn't need to be rewritten. A declaration file(s) could be included. There they could just declare types for all classes, methods, constants, etc. Similar to C header files. (This is how the DefinitelyTyped repository handles typings for untyped source repositories: https://github.com/DefinitelyTyped/DefinitelyTyped ) Ex: JavaScript: app.js function app(arg1,…

Given that React is already heavily invested in Flow types, there would be _some_ form of rewrite.

And like I said, Flow is providing sufficient benefit for the React team right now, and their focus is on expanding React's capabilities. Changing type systems is not on their radar as far as I know.

Re: Yarn's Future – v2 and beyond

#72

Post by jwalton »

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.

A very similar bug that we run into sometimes: https://npm.community/t/npm-install-or-npm-update-turns-a-bu...

Re: Yarn's Future – v2 and beyond

#73

Post by tchaffee »

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…

All the responses so far are seem really helpful but also quite specific. It might also be useful to understand the problem space at a higher level. We also see this in good database design. Which says that every record should always have a unique id that is not related to any of the other data. This allows you to freely change things like product descriptions, short name, SKU, price, weight, etc. Because you know that no matter what else changes, you have a unique ID to refer back to, that will get you to that product. Since a unique ID is often a random looking string, there is nothing stopping you from also having a human friendly lookup code for a product. For example, unique id is 186746, but the lookup code is BRWNCOUCH37. If the couch doesn't change color, the lookup code stays good. But if it does, you can change even the lookup code. Because the product unique id remains 186746.

So unique IDs are useful in many places other than just error codes. Hope that helps.

Re: Yarn's Future – v2 and beyond

#75

Post by tonyhb »

misiti3780 wrote: post #64

> The codebase will be ported from Flow to TypeScript. To understand the rational please continue reading, but a quick summary is that we hope this will help our community ramp up on Yarn, and will help you build awesome new features on top of it. Another major project moving from flow to typescript

This sucks because, in the first few years, flow had much better soundness and typescript had some serious issues. I'm a little disappointed and feel as though, similar with Kube vs Swarmkit, the worse technology is winning.

Re: Yarn's Future – v2 and beyond

#76

Post by dntrkv »

misiti3780 wrote: post #64

> The codebase will be ported from Flow to TypeScript. To understand the rational please continue reading, but a quick summary is that we hope this will help our community ramp up on Yarn, and will help you build awesome new features on top of it. Another major project moving from flow to typescript

> Yarn is currently fully covered by Flow types, and to be honest it works pretty well for us - the key part being “us”. Because we want to make it as easy as possible for third-party contributors to shim in and help us maintain this awesome tool, we'll switch the codebase to TypeScript. We hope this will help making the codebase feel more familiar than the projects your already contribute to.

Seems like Flow works just fine for them, they just want to make it easier for others to contribute.

Re: Yarn's Future – v2 and beyond

#77

Post by mattigames »

DevX101 wrote: post #59
h1d wrote: post #11

Earlier quoted context omitted.

Which part of npm acts unexpectedly?

Just moved to Yarn this weekend strictly because npm link (used to link to a local version of a package) doesn't work the way I want it to. Everytime I install a new package my previous `npm link` references break in the node_modules folder. `yarn link` keeps these reference. Just as I expect.

I just add a symlink to the folder inside node_modules (so it doesn't need to be on package.json), not the cleaneast but gets the job done.

Re: Yarn's Future – v2 and beyond

#78

Post by janpot »

ianwalter wrote: post #69
yaseer wrote: post #52

The JS ecosystem has its flaws, but one has to appreciate the speed at which momentum shifts, making clear winners obvious. The move towards TypeScript 'winning' has been fast, and to everyone's benefit.

Maybe it's a benefit when moving from Flow, but personally, I would rather have JS projects spend that time adding more tests than converting to static typing. Edit: changed strong to static.

sounds like their primary goal is 'attract more contributions' rather than 'strengthen the type system'.

Re: Yarn's Future – v2 and beyond

#79

Post by Klathmon »

scrollaway wrote: post #55
aylmao wrote: post #47

Earlier quoted context omitted.

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

Jest is getting migrated to Typescript as well, not just adding support for it. And then there's... whatever this is: https://twitter.com/jamiebuilds/status/1064649666275340288?l...

>And then there's... whatever this is:

I respect Jamie for the things done and built, but his views tend to be a bit extreme.

I agree that flow is not in a good place right now, but to say that they don't give a shit about the community just isn't true.

Flow has been making significant strides in community outreach, inclusion, and detailing their roadmap lately. And Facebook dropping flow would bring us toward a monoculture which I personally think is a bad thing (it's always good to have some competition to keep new ideas flowing and stuff improving), and Jamie advocating for it seems misguided and shortsighted.

Flow happily accepts contributions from outside people, but because of the somewhat esoteric language choice (ocaml) and the fact that it's significantly smaller in terms of community usage means that there isn't that many people to contribute anyway.

Re: Yarn's Future – v2 and beyond

#80

Post by BMorearty »

bouncing wrote: post #74
yaseer wrote: post #52

The JS ecosystem has its flaws, but one has to appreciate the speed at which momentum shifts, making clear winners obvious. The move towards TypeScript 'winning' has been fast, and to everyone's benefit.

Do people typically prefer TypeScript over ES6?

From what I've seen, yes.

I'm a big fan of ES6 and I haven't been a fan of typed languages for a long time but I'm liking using TypeScript. So are my coworkers.

Post reply on HN