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

npm best practices for using node 4 #8

Closed
allain opened this issue Sep 25, 2015 · 9 comments
Closed

npm best practices for using node 4 #8

allain opened this issue Sep 25, 2015 · 9 comments

Comments

@allain
Copy link

allain commented Sep 25, 2015

I love the ES6 features of Node 4 but I'm concerned that building an npm package using them will annoy users who include it from older Node versions.

How should I handle this?

@yosuke-furukawa
Copy link
Member

I also like ES6 features. But I don't like writing modules in ES6. npm ecosystem widely used ES5.
If you would like to create modules that every noder uses, you would be better to write ES5.
And we have another option, you can transpile your code from ES6 to ES5 using babel or traceur.
(But I don't like writing modules using transpiler... transpiled code is slow and these transpilers cannot cover all ES6 features.)

And according to our LTS plan, we can write ES6 code in December 2016. 💃
image

@allain
Copy link
Author

allain commented Sep 25, 2015

Interesting. Thanks for the response.

@julianduque
Copy link

@allain what you can do is use a prepublish npm script and https://babeljs.io/ to transform from ES6 to ES5, so you keep your source code in ES6 but publish to npm on ES6 without breaking the ecosystem

@bense4ger
Copy link

I'd suggest sticking with ES5 for the time being, but by all means code in ES6 and use Babel (or similar) to transpile.

Consider the target audience when writing something. Even small, agile places may not yet have moved to Node 4.x, and may not want to for a little while yet because of the associated overheads (testing, legacy code etc).

My personal view is to use new shiny things for my own stuff, but if I want something to be used by others then to avoid the cutting edge.

@allain
Copy link
Author

allain commented Oct 9, 2015

@julianduque I love the npm prepublish hook.

Unfortunately, from what I understand this would be run on very npm install, not just npm publish. This means, I think that any users of my package would be forced to install babel, even if the code was precompiled before it was published.

Please tell me my understanding is flawed.

Thanks

@Trott
Copy link
Member

Trott commented Oct 13, 2015

@allain You are correct that prepublish will run on install. There are workarounds for that, though.

@aseemk
Copy link

aseemk commented Nov 25, 2015

I believe prepublish is only run on local npm install — i.e. running npm install (with no other args) inside your module's directory.

I don't believe prepublish is run when running npm install <module>.

@williamkapke
Copy link

@allain this really depends on what the module is/does and what features you want to use. Many think working with a module transpiled from ES6 ES2015 is just as irritating as if it was done in coffeescript since contributing back to the project means setting up & running the transpiling too. Contributors want a low barrier to entry.

Since this question was asked about 6 months ago- I'll add to @yosuke-furukawa comment by noting that MANY more features have become available now (see http://node.green). Perhaps whatever you're writing is only applicable to newer apps and you can just publish with the engines property set to a version of node that supports the features you're using.

HTH

@Knighton910
Copy link
Contributor

closing for now, feel free to reopen.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants