HN Explorer

82 comments

[ 4.1 ms ] story [ 168 ms ] thread
dikaiosune
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.
abritinthebay
I’ve seen zero issue with npm locally or in production (have more issues with Webpack tbh)

What kind of problems?

0x0
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.
tuananh
any chance that you did `npm install --production` maybe? i think the lock file might be different for that case.
saas_co_de
yarn has resolved most of the issues already :)
abritinthebay
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.

rawrmaan
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)
jhgaylor
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.
abritinthebay
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.

tuananh
seems like a perfect use case for Docker.
jhgaylor
I whole heartedly agree. Would you tell that to my boss? :D
mtphil
Just out of curiosity, having never encountered any issues myself - what sort of issues have you run into with Yarn in CI/prod ?
abritinthebay
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.

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

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

abritinthebay
Well... I don’t use it anymore because frankly, there’s no need.
jsight
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.

abritinthebay
I was not, but even if I was that speaks to Yarn’s quality imo because they recommend that as an option.
saas_co_de
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.
abritinthebay
I have never seen that (or even heard of it). How bizarre.
nfriedly
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.
npolet
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).
mindcrash
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/

dikaiosune
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.
TAForObvReasons
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 :(
vacri
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?
TheCoreh
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)
nailer
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.

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

ojanik
Nuget. Can't remember last time i had issues.
jdavis703
> 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.

rejschaap
A breaking change should not be made lighthearted. It can cause a lot of inconvenience for your userbase.
che_shirecat
this is awesome, been looking forward to using async/await in production node.js without transpilers!
always_good
You've been able to for a while now.
wcarron
Server side at least. Not exactly confident that say, a vue-webpack site with no transpilation will play nicely with everyone's browsers.
ssijak
Is it that hard to add one step in webpack build?
wcarron
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.
che_shirecat
no you haven't, 6.x LTS does not support async functions.
always_good
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.

hammeiam
what's your experience been writing tests for async/await code?
always_good
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.

huangbong
Hopefully AWS Lambda adds support for this latest LTS... soon... we need async await without Babel transpilation.
koolba
I’ve long banished Babel thanks to Typescript. Still has a transpile step though much faster and no more plugin hell.
krainboltgreene
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.
roblabla
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.

qudat
"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.

krainboltgreene
Browser support is literally the tip of the iceberg.
amake
What literal iceberg would that be?
prophesi
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.
krainboltgreene
Here's the problem: Your 20s build times aren't because of babel.
prophesi
Ok, I'll bite. What's my problem?
krainboltgreene
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.

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

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

The whole Typescript & Webpack situation is very sad.

nojvek
I agree. I hope the Typescript team builds their own loader optimized for perf
Vinnl
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.
qudat
"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.

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

krainboltgreene
They are not different. They can both help developers write in confidence and integrity. Babel can do more.
alvis
Babel can't do type checking, right?
krainboltgreene
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.
coldtea
>"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?

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