-
-
Notifications
You must be signed in to change notification settings - Fork 731
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
ES6 style changes and node v4 #124
Comments
Hi @hueniverse , that sounds fine to me. We have no timeline to drop 0.10, unfortunately, and so we'll likely just fork this module for our ecosystems, if it becomes necessary. Likely, we'll sit on an old version unless there is some security issue :) |
If there are security issues we'll publish a 5.x patch since hapi 9.x will need it too. |
Even better :) Don't let us hold ya back ;) |
The "qs" dependency had a wrong version specified, and it was a simple ">=". Unfortunately, the latest version of "qs", as of two days ago, uses ES6 features so it won't be compatible with older Nodes. As there's nothing in RoboHydra that requires a recent version of Node (it seems to work even in Node 0.6.x), force the "qs" dependency to be slightly older for now. According to ljharb/qs#124 (comment) they will provide security patches for the 0.5.x series, so we should be fine.
qs now only supports node >= 4.0 and ES6 browsers, so this is a bit safer: ljharb/qs#124
This is fairly unfriendly to people using this library v. e.g. browserify or webpack. Have you considered still including a transpiled build in the npm package, then pointing the |
This is fairly unfriendly to force maintainers to also maintain builds while you can make it yourself. |
Aren't you already maintaining a browser package at Either way, the reason this comes up is because in general when producing browser bundles, best practice is to exclude anything from I like the approach you're taking with moving to use Node's ES6-supported features for Node code. It wouldn't be the end of the world if you dropped browser support in this library entirely, but right now you're actually shipping broken/outdated browser support via the distributed bundle, and would need to bring in Babel yourself to properly ship that bundle. |
You're right it is silly that we have an outdated browser build, but that's also why I have an open issue to remove that build. If you'd like to see browser support continued here, I'd be happy to hand the module over to you |
I just saw that issue, sorry. I have a few more JS packages than I can get around to maintaining at the moment, unfortunately, but I'd be happy to contribute a PR that fixes the browser build if that's something you're interested in. |
I'm more inclined to accept a PR removing all the current browser support |
I see - thanks. |
Thanks for keeping |
I am having problems with this library breaking my tests cause I don't intend to bundle node_modules... |
It's very sad to have a module that is published in such a way that it requires transpilation to be used in a browser or older node environment. Why is it difficult to add a babel prepublish step? |
@ljharb feel free to check-out the discussion around this at outmoded/hapi-contrib#67 |
Thanks, commented outmoded/hapi-contrib#67 (comment) |
use version 5. I'm locking this issue |
The hapi world is moving to only support node >= 4.0. This module is part of that world. I want to make sure the express community is aware of it as they are a significant user of this module. Also, this will affect use in the browser in pre-ES6 versions.
@dougwilson
The text was updated successfully, but these errors were encountered: