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

171–180 of 239 posts

Re: Yarn's Future – v2 and beyond

#171

Post by ianwalter »

jakelazaroff wrote: post #145
starefossen wrote: post #131

Earlier quoted context omitted.

Static types most definitely do not replace the need for tests!

Agreed! They replace the need for specific kinds of unit tests, e.g. making sure your functions accept and return the correct shapes. You still need to test the actual logic, and should be doing some sort of integration test on the application as a whole. In retrospect, my original response was too terse. Static typing and testing serve the same purpose, which is to make sure your application runs according to some m…

But it misses the point I was originally making. I was not suggesting they are mutually exclusive.

Re: Yarn's Future – v2 and beyond

#172

Post by brlewis »

mort96 wrote: post #150
jchw wrote: post #117

Earlier quoted context omitted.

Apples to oranges. You can use TypeScript without ES* -> ES5/ES3 transpilation. The compilation process may not be as fast as not having one, but it will be similar in speed to running a few sed commands over your source code. GCC startup time is going to be faster than Node.JS startup time, but that's irrelevant. We don't need to restart the compiler on each iteration. You can just use an auto reloader for that. And…

> We don't need to restart the compiler on each iteration. You can just use an auto reloader for that. Interesting, I hadn't considered that. I've always just had a build script (usually in package.json), and run that when I change something (either with an inotifywait loop or manually). It does make sense that if you're instead keeping one long-running node.js process instead of spawning a new node.js instance every…

Working well for me: https://www.npmjs.com/package/tsc-watch

Re: Yarn's Future – v2 and beyond

#173

Post by 4di »

tonyhb wrote: post #75
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.

I worked with Typescript for 2 years, then worked with Flow for 2 years and now I'm back on Typescript working for a big company.

I agree that Flow had better capabilities around soundness. But the tooling around Typescript really made me jealous, specifically in VSCode.

Near the end of working with Flow, Typescript was getting some cool capabilities like refactoring JSX for React apps.

Nowadays I can easily say that Typescript is a far better experience than Flow. There are updates every two months, adding some neat features that you might find in other languages.

Then you add in the power of surrounding tools and their ecosystems like TSLint and it really feels like a next-level coding experience where the tools start writing the mundane code for you, driven the core TS static analysis.

Re: Yarn's Future – v2 and beyond

#174

Post by [deleted] »

RyanCavanaugh wrote: post #108
dntrkv wrote: post #83

Earlier quoted context omitted.

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.

[deleted]

Re: Yarn's Future – v2 and beyond

#175

Post by eyelidlessness »

ianwalter wrote: post #167
eyelidlessness wrote: post #135

Earlier quoted context omitted.

While you're technically correct, this misses the value of static type checking vs type checking in tests. Tests must be written manually, must check every code path and must be updated whenever the underlying implementation changes, in order to achieve the results of static type checking. But types are declarative and will be checked automatically for every code path called.

I'm not missing the value we just have a different idea of what that value is, but anyway, this is a different, more specific topic than the one I originally brought up and one that I don't feel like engaging in.

I think it exactly addresses your original topic, but you're in no way obligated to engage it further. Have a nice day!

Re: Yarn's Future – v2 and beyond

#176

Post by cphoover »

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…

Nah YAML is better because of diffing.

JSON uses commas `,` which will show multiple changes when the last item of a list changes.

Re: Yarn's Future – v2 and beyond

#177

Post by cphoover »

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?

I'm a fan of functional programming over OOP as such, I don't need all of the OOP constructs just give me some immutable primitives, first-class functions and let's get to work.

There's not much I can do with a class that can't be accomplished with a simple function.

I think I've evolved in my thinking over this in the last several years of experience.

Re: Yarn's Future – v2 and beyond

#178

Post by dntrkv »

RyanCavanaugh wrote: post #108
dntrkv wrote: post #83

Earlier quoted context omitted.

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.

There is no difference if you limit the use of the tool to not use these features.

In my eyes, it's a philosophical difference between the two, Flow can be more easily integrated into an existing codebase by just adding //@flow at the top the file and has no features which can affect runtime code. Whereas TypeScript tries to be a different language altogether that uses a new file extension, adds new features, and has its own compiler.

When you can implement a tool like this using TS, let me know https://github.com/flowtype/flow-remove-types

Re: Yarn's Future – v2 and beyond

#179

Post by whatever_dude »

tonyhb wrote: post #75
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.

> This sucks because, in the first few years, flow had much better soundness and typescript had some serious issues

Most of not all of the issues had with types have been solved.

Flow had some major tooling/developer comfort issues from day one and none of those are solved. Not to mention a really closed development roadmap (understandable perhaps, but nonetheless bad).

As a developer, I'm glad TypeScript won. I want more tool/compiler/language/etc makers to understand that the developer experience matters. If someone makes a tool that only works well under one very specific setup and ignores everyone else, that's just very limiting.

Re: Yarn's Future – v2 and beyond

#180

Post by tlrobinson »

DuskStar wrote: post #169
donatj wrote: post #144

Earlier quoted context omitted.

I'd say safely merging YAML diffs however could be trouble. I don't know how restricted their YAML subset is, but in my experience it's so loose a format the only way to be sure YAML says what you think it says is to run it through a parser.

I think if you're merging lockfile diffs, you're doing something wrong! Merge the package.json diffs and regenerate the lockfile.

Yarn automatically resolves conflicts in yarn.lock if you run "yarn": https://github.com/yarnpkg/yarn/pull/3544
Post reply on HN