Node.js 8 Moves into Long-Term Support, Node.js 9 Becomes Current Release Line | Hacker News Reader

Node.js 8 Moves into Long-Term Support, Node.js 9 Becomes Current Release Line

medium.com

211 pointsstyfle81 comments

I was hoping to see v8 6.2 make into the LTS but apparently it will be merged into a future 8.x release in a few months from now.

v8 6.2 fixes a lot of Turbofan related regressions, for example: for in object performance [1]

[1] https://medium.com/the-node-js-collection/get-ready-a-new-v8...

Hopefully AWS Lambda adds support for this latest LTS... soon... we need async await without Babel transpilation.

I’ve long banished Babel thanks to Typescript. Still has a transpile step though much faster and no more plugin hell.

Mind sharing your process?

I have been having issues setting up my project structure with TypeScript

Here is my example with React + TypeScript + Webpack

https://github.com/styfle/react-server-example-tsx

It's faster because it's doing much less.

You're just mimicking babel with `babel-preset-typescript` + `babel-transform-object-rest-spread`, but without support for:

  - babel-preset-env
  - babel-minification
  - or any of the other dozen or so plugins that make development easier
  - any bug fixes or polyfills

I don't get why people think that they're doing something special by not using babel. Pre-babel life sucked.

For a side-project of mine, I decided to not use babel (or typescript or any transpilation at all), and I've got to say, post-babel life is awesome. Sure, you're limited in browser support. But it makes life so much easier, iteration time so much quicker, and we've got most of the es2015 goodies in browsers nowadays.

Being able to do the same on the backend side would be nice.

"But it makes life so much easier." Is this because you don't have to install a plugin for every thing you want? I found both babel and typescript to have a learning curve and a configuration step that required dev cycles being spent on getting it to work properly.

It really wasn't much of a difference in terms of getting things up and running.

Typescript has plenty of weird nuances and configuration settings that are required to get things working properly, just like babel.

If you're not using HMR and you're worried about iteration time, you're missing the biggest win. The time it takes to transpile a function is negligible.

http://matthewlehner.net/react-hot-module-replacement-with-w...

You don't need babel to get HMR.

Browser support is literally the tip of the iceberg.

What literal iceberg would that be?

It might be doing much less, but for most people it does plenty. You've still got your classes, arrow functions, modules, and whatnot. If your build iterations are averaging ~20 seconds on a device because of babel, I fail to see the problem with switching it out with Typescript.

Here's the problem: Your 20s build times aren't because of babel.

Ok, I'll bite. What's my problem?

I can't possibly know the actual problem. It could be a multitude of issues, hell it could even be one unofficial babel plugin, but it is absolutely not babel taking 20s.

Babel is essentially `cp` but with a slight twist: AST -> AST conversion. That doesn't take a huge amount of time.

This is purely anecdotal, and we could very well have done something wrong with our configuration, but I had my build iteration times cut in more than half after switching our project to CommonJS + ES6 Typescript from es2015-preset Babel.

I think we were using Gulp without any hot module replacement, so there are other ways we could have sped up our build time, but Typescript was good enough.

Should be noted that Typescript is slower for bigger apps if you're using Webpack.

The whole Typescript & Webpack situation is very sad.

I agree. I hope the Typescript team builds their own loader optimized for perf

In the version they released yesterday they have an improved watch mode, and they started they're working on providing an API to make loaders, among others, benefit from those optimisations.

"I've replaced X build step with Y build step." I don't understand the argument.

What I would love is for TypeScript to do one thing and that is it: static type checking. The fact that it does more than that to me is feature creep. I really wish something like Flow had the community support that TypeScript has because of its single responsibility.

TypeScript is never mean to be a replacement of Babel.

The spirit of TypeScript is code integrity. Imagine that you are working on a project which change often. In this case, refactoring and maintaining breaking changes are headache. How would you identify potential issues before pushing to CI and being punished by errors with no clue?

Babel and TypeScript are different. Babel is a transpiler which enable us to write modern syntax which are not widely supported, while TypeScript is a transpiler which help us to write in confidence and integrity.

They are not different. They can both help developers write in confidence and integrity. Babel can do more.

Babel can't do type checking, right?

It absolutely can! That said, the way it currently works is that babel-preset-flow and babel-preset-typescript both remove type annotations for the final build, essentially enabling flow or typescript to work without having to also be build engines.

>"I've replaced X build step with Y build step." I don't understand the argument.

Typescript does both X and Y steps, so what exactly don't you understand?

I love node 8. `await` and `util.promisify()` has completely changed how I approach JavaScript.

What a great position JS is in that 'await' is now default in stable server & build tools and the browser.

Stable Chrome has await top level in the console today too.

Yaay.

Do you know if top level await will ever be supported by node?

Relevant discussion: https://gist.github.com/Rich-Harris/0b6f317657f5167663b493c7...

RunKit allows top-level await today, too: https://npm.runkit.com/try-node-8

I'm definitely curious to see if the update to npm 5.5.1 resolves most of the issues people have seen on the 5.x releases. Otherwise having an LTS release with a rough release of npm might be pretty painful for a lot of the ecosystem.

I’ve seen zero issue with npm locally or in production (have more issues with Webpack tbh)

What kind of problems?

There are a bunch of linked issues at https://github.com/nodejs/node/issues/13815 and https://github.com/npm/npm/issues/16991, such as https://github.com/facebookincubator/create-react-app/issues....

I've had major trouble with the fact that the new package-lock.json doesn't sufficiently lock versions. In one working copy you can run "nom install" and everything works with no files or package-lock being changed. Yet, in another clean checkout, "npm install" brings in a different set of dependency versions despite having a -lock file, and things start to break. Yarn's yarn.lock seems to get this right.

any chance that you did `npm install --production` maybe? i think the lock file might be different for that case.

yarn has resolved most of the issues already :)

In my experience that’s simply not true.

We’ve seen more issues with Yarn in CI & prod than with npm 5.x

Both are great projects but npm is significantly more mature.

Agreed. I tried to switch to yarn a couple times now and it simply wasn't reliable (though the last attempt was a few months ago)

We finally got NPM out of the loop for production deploys and it's been glorious. We ship down a tarball of the repo after an npm install and include a node interpreter.

Ah well, that’s a whole different kind of system. Similar to doing a docker image ship.

Still have to do the install on a deploy server.

seems like a perfect use case for Docker.

I whole heartedly agree. Would you tell that to my boss? :D

Just out of curiosity, having never encountered any issues myself - what sort of issues have you run into with Yarn in CI/prod ?

Reliability, mostly. Also some strange cases where it would just plain fail (but then work if re-run).

We do use private scoped packages a lot so that might have some bearing on it.

I use private scoped packages (and monorepos, and yarn) too, and have generally had a fine time with it.

Would be interested in specifics of your reliability and failure problems too.

We just started using yarn workspaces and are running into weird issues where our private scoped packages don't always get installed on `yarn install`.

Yarn claims to be deterministic but I still need to `rm -rf node_modules` regularly when I run into weird build errors. It's quite strange.

Well... I don’t use it anymore because frankly, there’s no need.

Is there any chance that you are using npm to install yarn?

I had mistakenly setup our CI to do that at one point and it caused a lot of hard to debug problems.

I was not, but even if I was that speaks to Yarn’s quality imo because they recommend that as an option.

I guess it just depends on what you are doing. With npm 5.x installed packages started disappearing at random for me. Switched to yarn and no problems since.

I have never seen that (or even heard of it). How bizarre.

https://github.com/npm/npm/issues/17929 and linked bugs.

I've had it happen to me before. It's weird and annoying, and you basically have to nuke node_modules and sometimes package-lock.json, and then re-install everything to fix. That usually works.

Yea I'm big fan of it. Strange things used to happen with npm, dependencies would break, installs would fail etc... Maybe something to do with our build config, but since moving to yarn, no problems. We don't ever think about packages breaking or anything now (which is how it should be).

Yarn [0] might be a great alternative for those who have been bitten in the proverbial ass by npm a bit too many times.

[0] https://yarnpkg.com/lang/en/

I've recommended yarn for projects of mine that were broken by npm5, but it has some of its own issues. It's also not bundled by default which is really important for JavaScript tools that are used by beginners.

Our deployment setups explicitly roll back to npm 4. every version of npm5 has had problems with some step (currently fighting issues with react-native), including the latest 5.5.1 :(

Another option is pnpm(https://pnpm.js.org), a lesser known but much faster alternative.

How are we nearly a decade into the life of NodeJS and still suffering from problems with its package manager, which itself is up to version 5.x?

Because npm 5 was a pretty big update that fundamentally changed how a lot of npm portions work, in order to close the gap between it and Yarn, a competing package manager. The 5.0 release was super rushed IMO (I personally hit several bugs), but if you stuck to node LTS you skipped over most of the v5 breakage (now it works 99.99% of the time again, and when it doesn't work deleting node_modules usually does the trick)

npm v5 is still deleting private packages - the issue has been open, accepted and replicable since npm v5 was released - see https://github.com/npm/npm/issues/17929 nad various related issued linked from that page. This sucks if you use a monorepo.

yarn workspaces works a treat though.

package management is a harder problem than most people seem to want to admit. I've run into tons of issues with every package management system you can think of: rpm does some extremely dodgy caching stuff at times, navigating maven dependency trees to identify the offending version of slf4j that is harshing the vibe, etc.

I can't think of a single package management system that works well and people seem to love.

Cargo?

Nuget. Can't remember last time i had issues.

> which itself is up to version 5.x

Major version numbers in Javascript are defined using SEMVER. What this means is that a major version only implies that a breaking change was included (e.g. the API contract is different). It doesn't really have anything to do with a classic pattern where V2 is seen as the second phase, and V5 is seen as the fifth phase, etc, of a project.

A breaking change should not be made lighthearted. It can cause a lot of inconvenience for your userbase.

this is awesome, been looking forward to using async/await in production node.js without transpilers!

You've been able to for a while now.

Server side at least. Not exactly confident that say, a vue-webpack site with no transpilation will play nicely with everyone's browsers.

Is it that hard to add one step in webpack build?

No, it is not. But my point was that client-side javascript environments are not congruent in their support for all language features. Writing a boatload of async/await, object-spread, etc. code on the client and not transpiling is asking for trouble.

The original comment was about "production node.js", not browsers. But actually https://caniuse.com/#feat=async-functions looks very very good.

My mistake, you are correct.

no you haven't, 6.x LTS does not support async functions.

That you're stuck on LTS doesn't matter to everyone who's not and has been able to use async/await natively for a while now.

In other words, you've been able to for a while now, you've just chosen constraints that don't let you, so your response isn't very honest.

what's your experience been writing tests for async/await code?

Night and day. Just compare Koa's abstraction to Express'.

In Koa, you're inside one big top-level async function so all of your business code is as well. Any errors you have are async and bubble up.

Async/await is something that made Javascript concurrency not just bearable but better than the day-to-day code of other languages I use.

Great to see Node 8 move to LTS. We’ve gone ahead and made Node 8 the default version for RunKit.

You can try it out today: https://npm.runkit.com/try-node-8

It’s great to see the new LTS land on Halloween!

I wrote about Shipping ES Modules[0] if anyone is interested. Or just checkout the code on GitHub[1].

[0]: https://hackernoon.com/es6-modules-today-with-typescript-229...

[1]: https://github.com/styfle/copee

WOW, what's different?

https://github.com/nodejs/node/blob/master/doc/changelogs/CH...

Reply on news.ycombinator.com