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

141–150 of 239 posts

Re: Yarn's Future – v2 and beyond

#141

Post by venturin »

bouncing wrote: post #123
jinder wrote: post #13

Earlier quoted context omitted.

Both yarn and jest have announced they're switching to TypeScript. A corporate like Facebook would never allow that unless there was an internal shift in direction. I'd consider flow dead.

> A corporate like Facebook would never allow that unless there was an internal shift in direction. Sure they would. Flow has nothing to do with Facebook's business strategy, or its marketing campaigns, or even its corporate strategy. I'd be surprised if anyone on VP or higher even knows what it is. Insofar as "NIH" wins at big companies, it's when there's a business motive to promote a certain technology or FUD abou…

Engineering VPs very much know about it.

Re: Yarn's Future – v2 and beyond

#143

Post by symlinkk »

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 if needed) using $@. Similarly, scripts will have access to $1, $2, etc.

If you use either of these features your package.json will no longer work with NPM. Maybe they should call it yarn-package.json?

> Starting from Berry, we made it an explicit goal that each component of our pipeline can be switched to adapt to different install targets. In a way, Yarn will now be a package manager platform as much as a package manager. If you're interested into implementing PHP, Python, Ruby package installers without ever leaving Yarn, please open an issue and we'll help you get started!

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

That being said, it's cool that they're rewriting it in TypeScript.

Re: Yarn's Future – v2 and beyond

#144

Post by donatj »

wopian wrote: post #67
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…

npm's lockfile is a pain to diff in PRs because of the JSON format where what was maybe 20 changed lines in yarn is upwards of 80 from the brackets. With YAML and whatever format yarn.lock was in, the only changed lines are changes to the version resolutions, hash and dependencies.

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.

Re: Yarn's Future – v2 and beyond

#145

Post by jakelazaroff »

starefossen wrote: post #131
jakelazaroff wrote: post #81

Earlier quoted context omitted.

Static types are a form of test!

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 measure of correctness. We shouldn't be setting up one-or-the-other dichotomies — we can have both!

Re: Yarn's Future – v2 and beyond

#147

Post by kjaer »

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'! In a decent system language you can't get away with that, it's just a fake sense of security.

I don't know the comparison to system languages is fair though, because the use-case for JS is quite different from system languages.

Javascript (and by extension, Typescript) is commonly used to interface between the user and the network, both of which often are outside the bounds of the type system. Add to that any code that interfaces with plain JS, such as external libraries or legacy code. When dealing with those, it's natural to use statically untyped values and type ascriptions based on reasonable assumptions.

Taking that into account, I actually think Typescript's type system is fairly well-designed for the use-case. The problem isn't really with Typescript, it's just intrinsic to the use-case of JS.

Re: Yarn's Future – v2 and beyond

#148

Post by reconbot »

wopian wrote: post #67
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…

npm's lockfile is a pain to diff in PRs because of the JSON format where what was maybe 20 changed lines in yarn is upwards of 80 from the brackets. With YAML and whatever format yarn.lock was in, the only changed lines are changes to the version resolutions, hash and dependencies.

If you run `npm install` again it does detect the conflict and resolve it. https://docs.npmjs.com/files/package-locks#resolving-lockfil... But in practice I haven't found any changes that have been untenable to understand with a diff.

Re: Yarn's Future – v2 and beyond

#149

Post by eknkc »

azangru wrote: post #107
misiti3780 wrote: post #65

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

Because I don’t trust it. Had to do rm -rf node_modules too many times with npm.

Re: Yarn's Future – v2 and beyond

#150

Post by mort96 »

jchw wrote: post #117
mort96 wrote: post #112

Earlier quoted context omitted.

I haven't really ever seriously used flow or babel transpilation. My experience with compiled languages is mostly gcc which has initialized and started compiling in microseconds, or just writing plain JS which doesn't need transpilation. "Nearly the same performance as Flow/ES in Babel" isn't the benchmark I use.

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 time, tsc's slow start-up won't matter as much. I'll have to keep that in mind next time I end up doing typescript work.

I have used Angular, using a long-running webpack process which does angular template and typescript compilation, and I found that to be excruciatingly slow even for small changes, but I'm willing to bet that has more to do with Angular than with Typescript.

> C++ is a funny example to mention because it scales pretty poorly in the compilation time aspect

C++'s compile times are horrible, I won't try to defend it - waiting another eight hours for Chromium to compile because you need a build with debug symbols is just horrible. However, most of my time actually working on relatively small C++ code bases is pretty good; compiling each individual file doesn't take very long, and you only recompile the files which have actually changed, and recompiling one C++ file and re-linking the project takes around 0.4 seconds (unless you're doing something stupid like linking in all of webrtc, which we admittedly do for a couple of projects at work). Compiling a typescript file which just contains `console.log("Hello World");` on the other hand takes a bit over a second. (I know compiling hello world isn't very relevant when your compiler is a long-running process instead of a one-shot thing, I'm just including it because that's what my experience with tsc has been until now.)

Do you happen to know of any good resources for how you would run the compiler multiple times from one node.js process? I imagine webpack maybe does it already, but I would be interested to import the compiler as a library or something, and do some testing to see how big of a difference it actually makes to not start a new javascript VM every time.

Post reply on HN