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

221–230 of 239 posts

Re: Yarn's Future – v2 and beyond

#221

Post by fooey »

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…

and now TSLint is merging with ESLint so all that effort and rules duplication will be going away

Re: Yarn's Future – v2 and beyond

#222

Post by int_19h »

linkmotif wrote: post #220
int_19h wrote: post #218

Earlier quoted context omitted.

There are type systems that don't have anything like "any" - you find that in languages like OCaml or Haskell. But in TS, the main reason for "any" is interop with JS.

Thanks. So in OCaml/Haskell you can write perfectly sound programs?

Well, I mean, you can write perfectly sound programs in Java as well, or in TS. It's rather a question of how hard/easy it is to do so. Technically, any language that has either direct memory manipulation or FFI has the potential to do unsound things about types, but it takes a lot more effort.

Re: Yarn's Future – v2 and beyond

#223

Post by chowells »

linkmotif wrote: post #220
int_19h wrote: post #218

Earlier quoted context omitted.

There are type systems that don't have anything like "any" - you find that in languages like OCaml or Haskell. But in TS, the main reason for "any" is interop with JS.

Thanks. So in OCaml/Haskell you can write perfectly sound programs?

Haskell's type system still isn't sound. It just elimates that particular class of errors.

A lack of soundness is closely related to the Turing completeness, especially in languages based on HM. In an ideal world you would want a sound type system and not want Turing completeness, but the tooling doesn't exist to make those choices the most pragmatic right now.

Re: Yarn's Future – v2 and beyond

#224

Post by bluepnume »

wanted2 wrote: post #128
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.

> , and to everyone's benefit. Why? I've worked on large codebases in Coffeescript, ES6 and Typescript. Whatever this whole community sings and believes, but Coffeescript still wins for me. ES6 is still trying to catch up but will probably never reach the beauty and ease of Coffeescript. Both are transpilers, only ES6 with Babel is a total horror to manage (just upgraded a large codebase to Babel 7..). Typescript tak…

> Show me a Typescript codebase not using the type 'any'!

https://github.com/krakenjs/zoid

Admittedly Flow, not TypeScript -- but 99% the same thing syntax-wise. And yes -- it was difficult to set up and get working comprehensively, but now it's there, it's fairly easy to maintain, and it's invaluable when refactoring, accepting PRs, or adding new features.

Most people using `any` should really be using `mixed` (flow) or `unknown` (ts) which at least force you to check before you use some property of those types.

Re: Yarn's Future – v2 and beyond

#225

Post by bluepnume »

sebazzz wrote: post #3

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

I maintain PayPal's cross domain suite of libraries [0] and I'm fully intending to drop Flow for TS. The single thing I'm waiting for is https://github.com/Microsoft/TypeScript/issues/21699 since we use a fair amount of custom jsx rendering [1]. That's the one main thing (for me) that Flow is way stronger at right now.

[0]: https://medium.com/@bluepnume/introducing-paypals-open-sourc...

[1]: https://medium.com/@bluepnume/jsx-is-a-stellar-invention-eve...

Re: Yarn's Future – v2 and beyond

#226

Post by exogen »

spullara wrote: post #189

If you use the yarn cli and have tried the npm cli recently, why do you still use yarn? Are there big gaps that you find that NPM has failed to close?

Unfortunately npm is probably the biggest source of my daily development frustrations, even on the latest version.

I still come across bugs (that are definitely in npm itself) that have been around absolutely forever, like:

> npm ERR! cb() never called!

It sometimes gets its primary purpose, dependency resolution, wrong. I'll give it a perfectly reasonable package.json to install, which it will do, and then `npm ls` will still error with "missing dependency!" in some package. This should not be possible.

Related, it will put packages from the flattened tree in the wrong place. I can have a dependency (that other dependencies need, specified in their peerDependencies) specified in my top-level package.json and bafflingly, npm will still move it from top-level node_modules into the node_modules of something else that happens to use it, breaking the peerDependencies I was trying to satisfy.

On the install process: even if the total time to install is roughly on par with Yarn, I find that Yarn is much smoother. Whatever they're doing, they're yielding the CPU a lot more, and the result is I can actually work while it installs. npm meanwhile doesn't yield much during install and slows the whole system to a crawl.

Some npm commands are extremely neglected. The "success" message printed by one of the user/permissions related commands is simply: {}

Lastly, I will leave this terrifying comment here: https://github.com/npm/npm/issues/16528#issuecomment-3075400... – note this comment was left 2–3 years after receiving $10M in funding.

I don't blame them for being one-upped by Yarn at every turn, but they still fail to get the basics right, let alone innovate on things.

Re: Yarn's Future – v2 and beyond

#227

Post by coolreader18 »

spullara wrote: post #189

If you use the yarn cli and have tried the npm cli recently, why do you still use yarn? Are there big gaps that you find that NPM has failed to close?

Kind of ridiculous, but yarn's CLI just feels better. It's a bit simpler, `install` doesn't really seem like an "add to package manifest" command word, there's the `global` subcommand for managing global command-line tools vs `-g`/`--global`, and no command aliases, which I like more for some reason. For me it's mostly personal preference; ergonomics would be the key difference for me. Plus, the upcoming stuff mentioned in this issue has got me excited!

Edit: also, in my experience using npm for some little stuff recently, yarn is still faster installing packages.

Edit2: I also like the ability to run scripts/commands from the base level of command, e.g. `yarn start`, `yarn webpack --mode production`, `yarn build:web`

Re: Yarn's Future – v2 and beyond

#228

Post by coolreader18 »

symlinkk wrote: post #146
jcolella wrote: post #20

The addition of vulnerability scanning was the only reason our company switched back to npm from yarn. Other than that, yarn offers a great experience

Yarn has this too (although it uses the NPM audit database): `yarn audit`.

Oh, I didn't know that! Here's some resources about it if you haven't heard of it either:

documentation; https://yarnpkg.com/lang/en/docs/cli/audit/

original feature issue: https://github.com/yarnpkg/yarn/issues/5808

release comment in that issue: https://github.com/yarnpkg/yarn/issues/5808#issuecomment-441...

Re: Yarn's Future – v2 and beyond

#229

Post by nhanb »

maw wrote: post #154
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…

I don't see the need for PHP, because composer is one of the few things I like about it. And I don't know enough about Ruby to have an opinion there. But something for Python that actually works? Yes, please!

For python we've been using poetry[1] at work. Dep resolution is a bit slow but otherwise it works well enough, definitely a saner choice than pulling in a completely different stack just for one tool.

[1]: https://poetry.eustace.io/

Re: Yarn's Future – v2 and beyond

#230

Post by moogly »

towaway1138 wrote: post #82

Yarn has over 1500 open bugs. Rather than working on changes, it'd be nice to stop and address these.

And npm had 2166 at the time they archived their old GitHub repo, moved over to npm-cli (with issues disabled), and have all their issues in a Discourse forum, so you can't get an overall count, nor any connection to PRs and commits.

So I'm not sure you can glean too much from just looking at an issue count in isolation.

Post reply on HN