Node v6.9.0 (LTS)
nodejs.org
nodejs.org
Probably the most important change other than improvements in es2015 support.
If that’s the only thing you’re transforming, my advice would be to stop and just use function () {}.
Depending on your target market, you may be stuck on ES5. Your users' browser behavior determines when you can remove the shims and transforms, and if they aren't upgrading you can't really force them to upgrade the browsers.
Please yes
You can use one of a number of modern targets which will avoid the need for the various polyfils etc... but if you need current safari and any IE support, you will at least need dual build paths, which isn't too bad. I kind of wish there was a babel preset that was meant to be used in conjuction with Financial Times' polyfill.io
First, it doesn't matter how fast browsers moved. Currently they're moving pretty damn quick if you ask me but it doesn't matter because you need to know your audience and what browser(s) they use.
Second, I don't understand the want or need to include "hundreds of MBs dependencies to transform a arrow function". Why do you have to use an arrow function? Yeah it looks nicer but if you're complaining about how much dependency it brings in why not just not use it? Don't get me wrong I like ECMAScript 2015 but if you don't want to bring in the huge amount of transpiler dependencies ECMASCript 5 is still super easy to write.
and if we insist on crazy tooling chains, how about getting some real benefit – like coffeescript (?-operator anyone) or typescript (yes, typing can help, just look at swift)?
- http://requirebin.com/?gist=8f13d5147c1c252ab1691115bfa8b7c5
- http://requirebin.com/?gist=06e8c85fcaca56c9651c6aabd0d91476
fs.saveFile(file, function(err){});
It's not limited to Promises, or even unique.
var fs = require('fs');
fs.writeFile('foo.data', function(err){
// A typo here will lead to an exit and stacktrace
sadsad
});
It is limited to Promises, because they're supposed to help us deal with error propagation, and pass exceptions through to `.catch()` handlers. But if that catch handler is missing, crickets, even for outright invalid code. That doesn't happen with any other construct in JS afaik.
The parent's point is that you still aren't doing anything with the callback errors (that first parameter to most node-style callbacks) and those silent swallows are a lot harder to deal with than Promise's silent swallows because node callback error handling is a convention that is easily missed/forgotten/ignored, whereas Promises always "bubble" exceptions "down the chain" and fixing global unhandled exception handlers in Promises is a lot easier (and done at a platform level) than fixing a codebase full of bad node-style callbacks.
Btw, I prefer Promises and the error-bubbling approach in principle for the reasons you're getting at, but the current implementations (especially in p0lyfills like es6-promise) are simply broken, due to the standards themselves being lacking. See this comment for fact the fix has been in draft for a while now: https://github.com/stefanpenner/es6-promise/issues/70#issuec...
This "bug" in some of the Promise runtimes could just as easily be handled by forcing every Promise chain to end in a .catch((err) => /* ... */). Requiring even this little bit is less onerous than node-style callbacks where every "link in the chain" needs explicit opt-in, with Promises you only "have to" opt in and deal with boundaries, just like try-catch in most languages.
Yes, it's not great that Node and some of the browsers initially "missed" the "great try/catch in the sky" catch all logging, but again that is easily resolved at the runtime platform level whereas node can't possibly tell you if a developer missed an if (err) throw err somewhere in a callback chain 10-levels deep and across three or four dependencies.
They silently swallow all runtime exceptions, not 'error from reading said file you told me to read, that there should, by any sane degree be SOME KIND of error handling for, and for anyone serious about programming in a dynamic language, also test coverage for'.
Those two things are different issues, on different levels.
> Yes, it's not great that Node and some of the browsers initially "missed" the "great try/catch in the sky" catch all logging, but again that is easily resolved at the runtime platform level
That's all my original comment said. The platforms (actually the spec) failed to get it right initially, the implementation was broken and now it is fixed.
You're always welcome to write a replacement if you find it unsuitable.
Coincidentally I was annoyed by this very fact a few years ago so I developed https://www.npmjs.com/package/callback-wrappers which made the boilerplate for common error handling scenarios (logging, throwing, exiting, emitting, etc.) much terser and moves it to the end of the functions so it's less in your face. Never made much use of it, and it's so non-canonical that I'm loathe to advocate it too much, but it would make me happy some sort of standard syntactic sugar could be introduced that allowed comparable brevity.
Technically, it propagates the error along to any dependent promises. If nobody's handling errors, then yes, they get swallowed. If that bugs you, all you have to do is add this once when your app starts up:
process.on('unhandledRejection', function(ex) {
console.error(ex.stack);
process.exit(1);
});
Like, you want to be careful not to open yourself up to cascading failure, but if my application has a random exception, the 100ms start up time of the JavaScript VM means its almost always worth the cost of restarting to ensure your application isn't in an unstable state.
Surely the best practice is to use something like koa or otherwise create a promise chain with a top-level 500 handler.
I run a node app that serves ~500M requests a day that is configured to die on exceptions, it just means that we do everything we can to prevent them (unit tests, linters, etc) and take them very seriously when they happen.
Technically however, what that polyfill is doing is 'on-spec'. Note that your `process.on('unhandledRejection')` thing is clearly outside spec as `process` is a Node thing, not a JS thing.
I'm not sure all of it still stands. Bluebird is in C. Native is in javascript.
Edit: i'm wrong
nvm install lts/boron && nvm alias default lts/boron
You may need to update nvm before that works:
( cd "$NVM_DIR" git fetch origin git checkout `git describe --abbrev=0 --tags --match "v[0-9]*" origin` ) && . "$NVM_DIR/nvm.sh"
If you have can you paste the exact message you're getting?
λ ~ ◆ antigen bundle lukechilds/zsh-nvm
.Cloning into '/Users/drinchev/.antigen/repos/https-COLON--SLASH--SLASH-github.com-SLASH-lukechilds-SLASH-zsh-nvm.git'...
remote: Counting objects: 228, done.
remote: Compressing objects: 100% (47/47), done.
remote: Total 228 (delta 16), reused 0 (delta 0), pack-reused 178
Receiving objects: 100% (228/228), 29.54 KiB | 0 bytes/s, done.
Resolving deltas: 100% (91/91), done.
Checking connectivity... done.
Installing nvm...
fatal: destination path '/Users/drinchev/.nvm' already exists and is not an empty directory.
fatal: Not a git repository (or any of the parent directories): .git
fatal: Not a git repository (or any of the parent directories): .git
λ ~ ◆
Although it shouldn't be trying to install over your previous installation, it checks if nvm exists first with `[[ ! -f "$NVM_DIR/nvm.sh" ]]`.
Out of interest what does: `[[ ! -f "$NVM_DIR/nvm.sh" ]] && echo "nvm doesn't exist" || echo "nvm exists"` return?
If you wanna try it out you could backup your "$NVM_DIR/versions" folder and restore it. That holds all your node installs and global modules.
λ ~ ◆ [[ ! -f "$NVM_DIR/nvm.sh" ]] && echo "nvm doesn't exist" || echo "nvm exists"
nvm doesn't exist
λ ~ ◆
Is it a symlink or something? Does `ls "$NVM_DIR"` list nvm.sh anywhere?
I've opened an issue, because I think we're polluting HN
Welcome, Boron! We've been waiting for you :)
Windows Vista was released in 2007, OS X 10.7 in 2011.
For some reason, third-party software seems to support old Windows versions much longer than OS X. Meanwhile, Apple stops supporting old hardware in new OS X versions quite quickly (IMHO), probably for business reasons.
I had one Macbook in the past that I had to put Linux on, just because most software dropped support for the most recent available OS version.
Apple may seize support older hardware earlier than Microsoft does for a very easy reason: because they can. With the insane amount & combinations of hardware Windows has to support, there's no point in adding anything that's somewhat specific – plus they have a lot more of the "enterprisey" customers with a 15-year support contract and underfunded IT budget.
There are quite a few Macs in large companies nowadays, but from what I've seen, they are much more likely to adopt a consumer-like support system, i. e. giving root to the users or letting them individually buy & upgrade within a certain budget. They also tend to update more often, possibly because buying a Mac is already an indicator that they're willing to spend more / that they care about their tools.
It's also the complete opposite on mobile phones: not rare for Android phones to sometimes not even support a version that was already released when you bought it, whereas iPhones are good for about 4 iOS versions I believe.
https://hackernoon.com/node-js-tc-39-and-modules-a1118aecf95...
Promises, afaik, are always asynchronous. Maybe the spec changed (I'd welcome it for sure) but last I read it, resolve or rejection handlers must be called in the next tick. Even if something can be executed immediately, it'll still wait till next tick. This obviously means there's always a wait associated with promises, hence they are always asynchronous.
I wish this article would go into more detail on what the edge cases are with the unambiguous module syntax – I thought that was an unusually elegant solution in this community.
In this scenario, I believe the idea is that the module could be loaded synchronously, but the Promise would still be resolved or rejected in the next tick.
Right now, Node uses require(). What he means here is that while this does return a Promise, the underlying loading of the module doesn't have to be asynchronous, you could just do something like this:
function import(module) {
return Promise.resolve(require(module));
}
> I thought that was an unusually elegant solution in this community.
The biggest issue with unambiguous module syntax is that, since you have to parse modules before finishing the resolution, it could drastically lengthen startup time.
Regarding parsing modules – that's a fair point but surely this has to be done anyway? For ESMs you have to parse them to build the binding map, and for CJS you have to parse to evaluate; either way the modules get parsed at some point so why would this in any way be an additional overhead?
It does seem like it'll be a while before we can use this in an Node.js LTS.
This is a funny one, in conjunction with the facts about npm that 1) npm has no public programmatic API (and zero docs on it), 2) npm devs encourage you to exec() stuff and read stdout, as all the internal methods can be changed/removed at any time, also in non-semver-major.
I used to have script doing `npm view | grep ...` which now fails under node 6. The best solution I guess is to use a hardcoded version of npm as a dependency and rely on programmatic API rather than stdout.
Also, does anyone know if there is a way to get babel to output code targeting Node v7? Like, just stuff in the 'latest' preset that isn't out-of-the-box (with or without the flag).
Does exactly that - feature based Babel transforms