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

191–200 of 239 posts

Re: Yarn's Future – v2 and beyond

#191

Post by lmm »

mrspeaker wrote: post #45
lmm wrote: post #30

Earlier quoted context omitted.

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/aband…

Are you gonna hardcode all the HTML and CSS as well? I would expect resurrecting a 100% compatible toolchain for a mainstream source format 20 years from now will be easier than resurrecting a 100% compatible browser. Especially if that format is a stricter/less ambiguous one like typescript.

Re: Yarn's Future – v2 and beyond

#192

Post by Siilwyn »

fold_left wrote: post #190
cphoover wrote: post #177

Earlier quoted context omitted.

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.

You can continue to code the way you've been enjoying, just with the option to type your inputs and outputs if you choose to. Writing classical OOP isn't imposed on you by TypeScript, nor do you miss out on anything by not writing classical OOP.

Typescript doesn't support typings for functional concepts that libraries like Ramda & Sanctuary use though.

Re: Yarn's Future – v2 and beyond

#193

Post by arcatek »

symlinkk wrote: post #143

I've got to say I'm not a big fan of some of these changes and I think they're biting off more than they can chew. > Writing posix command lines inside your scripts field will work regardless of the underlying operating system. This is because Berry will ship with a portable posix-like light shell that'll be used by default. > Scripts will be able to put their arguments anywhere in the command-line (and repeat them i…

> If you use either of these features your package.json will no longer work with NPM.

Yes and no. In the case of the `postinstall` script (which might indeed have to run on npm setups) you might want to refrain using those features. In any other case you simply won't use npm if you use them, because those are local scripts that only you and your team will use - and regardless of those features you should all use the same package manager anyway.

> Noooo, god no. Package management is a gargantuan, complicated task, and these languages all have their own solutions already.

We won't spend much time on it ourselves - as you mentioned other solutions exist and we have to pick our fights. Still, I believe this is a necessary move if we want to make our codebase clear and easy to contribute to. It's not so much about Yarn supporting everything than it is about making sure that we don't end up with a monolithic system hard to maintain.

Re: Yarn's Future – v2 and beyond

#194

Post by arcatek »

exogen wrote: post #165
arcatek wrote: post #152

Earlier quoted context omitted.

> Which lightweight shell will be used on Windows? Does it also bundle standard unix tools (if a script pipes to grep or less for example)? It will be in-house, and very basic. We don't intend to rewrite bash, just to provide the basic experience that is usually needed when adding script into the `scripts` field. For more complex needs we'll simply offer a way to opt-out and use the native shell, or to call Node scri…

I'm assuming that lifecycle scripts (and scripts called by lifecycle scripts) in particular will still need to use common Windows-supported syntax? Even if the devs of the package are guaranteed to be using Yarn, people installing the package might still be using npm. So I assume some caveats apply to some scripts, right? p.s. I love Yarn :)

The `postinstall` scripts would likely be better off without using those features, indeed. But in the end, your packages would be better off without `postinstall` scripts anyway ;)

Re: Yarn's Future – v2 and beyond

#195

Post by jakelazaroff »

ianwalter wrote: post #171
jakelazaroff wrote: post #145

Earlier quoted context omitted.

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.

My interpretation of your point was that unit tests are more valuable than static types, and I don't think that's necessarily true. They're both forms of testing, and it's important to recognize their strengths and weaknesses.

Static types won't help with your application logic, but they will (for example) ensure your function inputs and outputs are the correct types, help document your code and ensure consumers call your code correctly. Unit tests can only do the first one, and it's more verbose and brittle.

Re: Yarn's Future – v2 and beyond

#196

Post by wafflesraccoon »

4di wrote: post #173
tonyhb wrote: post #75

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

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…

I'd agree with everything you've said. Flow isn't bad but after working with TypeScript I could never go back. You're spot on with the tooling and ecosystem.

Re: Yarn's Future – v2 and beyond

#197

Post by kjaer »

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

Not only that, but it's another Facebook project moving from Flow to Typescript. Jest also announced a Typescript migration last week: https://github.com/facebook/jest/pull/7554

Re: Yarn's Future – v2 and beyond

#198

Post by fold_left »

Siilwyn wrote: post #192
fold_left wrote: post #190

Earlier quoted context omitted.

You can continue to code the way you've been enjoying, just with the option to type your inputs and outputs if you choose to. Writing classical OOP isn't imposed on you by TypeScript, nor do you miss out on anything by not writing classical OOP.

Typescript doesn't support typings for functional concepts that libraries like Ramda & Sanctuary use though.

That's also true. TS has more to do to improve working with functional JS.

Re: Yarn's Future – v2 and beyond

#199

Post by ggregoire »

wafflesraccoon wrote: post #196
4di wrote: post #173

Earlier quoted context omitted.

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…

I'd agree with everything you've said. Flow isn't bad but after working with TypeScript I could never go back. You're spot on with the tooling and ecosystem.

Also, TypeScript has a roadmap and when you report a bug, the devs actually reply. Flow doesn't have any of that.

Re: Yarn's Future – v2 and beyond

#200

Post by whatever_dude »

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.

Oh man, I get that all the time, hate it so much.
Post reply on HN