Earlier quoted context omitted.
Static types are a form of test!
They are a compile time contract at best, they are nothing like a test.
Half the tests I write for Javascript code are type tests. Typescript does that much better.
Yarn's Future – v2 and beyond
101–110 of 239 posts
Re: Yarn's Future – v2 and beyond
#102> Writing posix command lines inside your scripts field will work regardless of the underlying operating system
That is very nice. No need to install other dependencies just to do 'rm -rf'
Re: Yarn's Future – v2 and beyond
#103Earlier quoted context omitted.
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.
This is certainly how I feel; there are large parts of my codebases that I don't think will convert well if I was to change, where we leveraged flow to great effect. However I certainly take the point that flow has been developer hostile. When we have had issues it has been impossible to get a response (here is a demo, is this a bug or in the pipeline?). Though flow is v0.91 and Typescript is 3.2, i don't know if i c…
Typescript has been moving fast, but they haven't broken that many things. The API and Language Server have changed obviously four times from a semver perspective, but in general the language itself has been extremely stable with great backwards compatibility, and most of the type system strictness additions are behind opt-in flags making upgrades usually as gentle as you prefer them to be (depending on your attitude to strict type checking).
(I had projects that started with TS < 1.0 and they all still parse and compile today, albeit with tons of lint warnings, particularly to use a better module system than AMD with pre-ES2015 TS imports, and all sorts of new type strictness options to turn on to make them all the more type safe.)
Re: Yarn's Future – v2 and beyond
#104The 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.
One huge thing we're giving up when moving from JS to TS is iteration speed though. The typescript compiler is not only an additional step, it's also ridiculously slow compared to other languages' compilers.
Disagree. The TypeScript compiler is quite fast even on large projects. Build systems that are unable to properly parallelize builds are common in the JS world these days so you are probably experiencing tsc much slower than it is.
That said, Babel now supports TypeScript so you should get nearly the same performance with TypeScript as you did with Flow or even just plain ES transpilation. That way you can do typechecking as a separate step like you would have done with Flow.
Re: Yarn's Future – v2 and beyond
#105The 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.
One huge thing we're giving up when moving from JS to TS is iteration speed though. The typescript compiler is not only an additional step, it's also ridiculously slow compared to other languages' compilers.
classic fallacy of speed lost by dynamic code “i can’t hit save and refresh the page” vs compiled “i can’t make changes without breaking 5 things”
Re: Yarn's Future – v2 and beyond
#106Earlier quoted context omitted.
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.
Oh— can you point me at a file in particular? I had a look around the codebase and didn't see anything but plain JS. Might have been looking in the wrong places. And I certainly get your point. However I wonder if they'd consider community-contributed TypeScript declaration files to the official repo as they wouldn't cause conflicts with the Flow system—
Flow types are _everywhere_ in the codebase.
To pick a specific example, here's the file that implements the core logic for the new Hooks feature:
https://github.com/facebook/react/blob/6cb26774e27e03c7d5d6e...
As for the TS typings, there's been lots of agitation from people asking them to be officially included and shipped with React. But, again, the React devs themselves aren't TS users (that I know of), and so they don't have the expertise to write and maintain those typings. Better that they be left over in DefinitelyTyped for the community to maintain.
(I'm a Redux maintainer, and I feel exactly the same way about the typings for React-Redux. I don't have any actual TS experience myself yet, and I couldn't do anything useful in regards to the React-Redux typings. Plus, I've got far too much else on my plate to worry about those.)
Re: Yarn's Future – v2 and beyond
#107serious question, if you are starting a new project today why would you choose to use npm over yarn?
Because npm is a standard (default) package management tool that comes with node.
After getting `package-lock.json` and `npm ci`, I would rather wonder why choose yarn instead of npm.
Re: Yarn's Future – v2 and beyond
#108Earlier quoted context omitted.
> 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 (whi…
This is where I see a big difference between Flow / TS. With Flow, the type annotations are just stripped away, none of your Flow code affects runtime code. This is not so with TS since you have things like Enums, which will be compiled into objects and are part of your runtime code.
If you write type annotations in TS, they're stripped away.
If you write type annotations in Flow, they're stripped away.
There's no difference. TS has some additional features which are purely optional that don't get purely stripped out, but you're not mandated to use them.
Re: Yarn's Future – v2 and beyond
#109Earlier quoted context omitted.
Static types are a form of test!
They are a compile time contract at best, they are nothing like a test.
Test and compile time contracts both check invariants.
Abstractly speaking, there's no big conceptual chasm that separates a test in a test suite from a test the compiler makes.
Re: Yarn's Future – v2 and beyond
#110Earlier quoted context omitted.
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 mono…
>I respect Jamie for the things done and built, but his views tend to be a bit extreme.
They might be in general, but these sound like some easily objectively checkable claims:
"If you want visible proof of this [Flow not caring for the community], just look through the repo. PRs are never merged. Issues are never addressed. Pretty much all of the activity there is done by a couple people in the community. Critical issues stay open for years. They do all of their development internally"