node v4

[hueniverse]

node v4 is out and you should be pretty excited! There is a lot to love about the new version, both technically and community wise. Between the new v8 engine, the hundreds of bug fixes and improvements, and a responsive core team addressing issues, we want to make sure the hapi.js community can jump right in and take advantage.

Today.

With the exception of some non-hapi-specific edge cases, the core hapi module and every single one of its dependencies have been tested on the new node version and passed successfully. This gives us the confidence to recommend node v4 as the new standard development environment for hapi users.

That said, we recognize that moving from the current official hapi node version of 0.10 to 4.0 is a big deal and can take months in a large enterprise or sensitive production environments. Like any new major release of node, there are likely to be bugs that will only show up at scale. So we don't want to rush anyone into making a move they are not ready for.

hapi v10

Today we are publishing a new major version of hapi - version 10 which is identical to the last version published (v9.3.1). We are doing so to enable us to immediately take advantage of new node and JS APIs available in node v4 without having to confuse hapi API changes with node dependencies. If you are currently using hapi v9, you can immediately switch over to v10 after moving to node v4.

We expect to release a few hapi v10 releases over the next few weeks using some of the new JS features such as const, let, and Promises for APIs currently requiring callbacks. These will be patch and minor releases.

hapi-lts

We are also announcing today an LTS hapi brach available under the @9.x.x versions. The LTS branch will continue to include hapi v9 releases for current node v0.10 users. We will do our best to port as many important security bug fixes from the master branch. The LTS releases will continue to support node v0.10 until June 2016.

The LTS distribution is led by Nathan LaFreniere and sponsored by &yet.

[AdriVanHoudt]

This is awesome, I really like the plan!

[cjihrig]

What is the plan for new ES6 features (which ones will you allow, and any relevant style guide updates)?

[hueniverse]

@cjihrig That's for another thread in hapijs/contrib.

[gergoerdosi]

Will hapi-lts support node v4.0 and greater or is it v0.10 only?

[hueniverse]

@gergoerdosi it should but if there is a conflict in the future, it might not.

[Fishrock123]

Promises for APIs currently requiring callbacks

Please don't require/use native promises for this. They are super slow.

[corbinu]

@Fishrock123 What about using Bluebird promises I just ran a quick benchmark on the latest version on on my laptop on node 4.0.0

Success
file                                            time(ms)  memory(MB)
callbacks-baseline.js                                244       32.41
promises-bluebird-generator.js                       319       34.87
promises-bluebird.js                                 439       45.18
promises-ecmascript6-native.js                      1223      194.05

Failure
file                                               time(ms)  memory(MB)
promises-bluebird.js                                 484       85.98
callbacks-baseline.js                                559       37.86
promises-bluebird-generator.js                       568       88.46
promises-ecmascript6-native.js                       2831      504.09

So looks like native promises are still 330-500% slower and uses about 500% more memory where as bluebird can be 90-200% on both compared to callback.

Maybe bluebird would be the better option?

[hueniverse]

Let's not have a promises debate here please.

[corbinu]

@hueniverse I was simply trying to find a solution to Fishrocks concern as I was not aware the difference was that bad before reading it here... I will leave it be though

[SteveALee]

Great strategy!

[tanepiper]

@hueniverse The core issue from this is the hapi ecosystem and how the modules are currently set up. Already today I'm seeing that hapi-auth-cookie has:

"peerDependencies": {
    "hapi": ">=8.x.x"
  },

Now despite me switching our code to hapi-lts, with the ecosystems setup hapi 10.0.0 is still being installed. While it should not cause any issues in our code, last week most of Thursday was spent tracking down an issue that happened because someone pushed out a broken hapi module (confidence) and I'm concerned this path might lead to more issues that the solutions it fixes.

[hueniverse]

@tanepiper It's probably going to require npm 3.x which no longer installs peers, only outputs warnings.

[kidtronnix]

@Marsup thanks for pointing me to here. Super excited about the new changes to hapi and the hapi-lts project.

[mgol]

@tanepiper If a package A has hapi in its peerDependencies and package B depends on A, package B should also explicitly depend on hapi. It's required in npm 3 but even in npm 2 it's the best strategy. If someone is doing it differently, they're doing it wrong.

[tanepiper]

@mzgol The specific issue was moving to Hapi LTS on a project, but Hapi was still being installed and it was a concern that it might have side effects. No issue now, I've moved on to another project and we've moved to Node4 and NPM3 anyway, so no need to continue with the LTS version.

[hueniverse]

We no longer use the LTS module. We published 9.x under hapi.

[lock]

This thread has been automatically locked due to inactivity. Please open a new issue for related bugs or questions following the new issue template instructions.