Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

node v4 #2765

Closed
hueniverse opened this issue Sep 11, 2015 · 17 comments
Closed

node v4 #2765

hueniverse opened this issue Sep 11, 2015 · 17 comments
Assignees
Milestone

Comments

@hueniverse
Copy link
Contributor

@hueniverse hueniverse commented Sep 11, 2015

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
Copy link
Contributor

@AdriVanHoudt AdriVanHoudt commented Sep 11, 2015

This is awesome, I really like the plan!

@cjihrig
Copy link
Contributor

@cjihrig cjihrig commented Sep 11, 2015

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

@hueniverse
Copy link
Contributor Author

@hueniverse hueniverse commented Sep 11, 2015

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

@gergoerdosi
Copy link
Contributor

@gergoerdosi gergoerdosi commented Sep 11, 2015

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

@hueniverse
Copy link
Contributor Author

@hueniverse hueniverse commented Sep 11, 2015

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

@Fishrock123
Copy link

@Fishrock123 Fishrock123 commented Sep 12, 2015

Promises for APIs currently requiring callbacks

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

@corbinu
Copy link

@corbinu corbinu commented Sep 12, 2015

@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
Copy link
Contributor Author

@hueniverse hueniverse commented Sep 12, 2015

Let's not have a promises debate here please.

@corbinu
Copy link

@corbinu corbinu commented Sep 12, 2015

@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
Copy link

@SteveALee SteveALee commented Sep 12, 2015

Great strategy!

@tanepiper
Copy link

@tanepiper tanepiper commented Sep 14, 2015

@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
Copy link
Contributor Author

@hueniverse hueniverse commented Sep 14, 2015

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

@kidtronnix
Copy link

@kidtronnix kidtronnix commented Sep 15, 2015

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

@mgol
Copy link

@mgol mgol commented Nov 22, 2015

@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
Copy link

@tanepiper tanepiper commented Nov 23, 2015

@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
Copy link
Contributor Author

@hueniverse hueniverse commented Nov 23, 2015

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

@lock
Copy link

@lock lock bot commented Jan 9, 2020

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.

@lock lock bot locked as resolved and limited conversation to collaborators Jan 9, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
10 participants