
Node.js 7.6 Released - wonderfuly
https://nodejs.org/en/blog/release/v7.6.0/
======
roryrjb
So this, having V8 5.5 means async await is now stable and available without
command line flags? Awesome!

~~~
nailer
Yummy. No .then() chaining, no async.waterfall(), no pyramid. Not _totally_
seamless as parent scope has to be run with `async` but still excellent:

    
    
        async function logFetch(url) {
          try {
            const response = await fetch(url);
            console.log(await response.text());
          } catch (err) {
            console.log('fetch failed', err);
          }
        }

~~~
always_good
Here's my attempt at a slightly less contrived example:

    
    
        router.get('/users/:id', async (ctx, next) => {
          const user = await db.getUser(ctx.params.id)
          if (!user) return ctx.send(404)
          let data
          if (user.admin) data = await api.getSomeData(user)
          return ctx.render('show_user.html', { user, data })
        })

~~~
yamalight
This would quietly swallow all the errors though

~~~
always_good
That's actually one of the whole points of using promises: it _doesn 't_
swallow errors.

Errors bubble up to the top-level. It's the old callback-style that swallows
errors unless you manually handle them every time. It's one of the chief
advantages of promises.

In my case, errors bubble up to error-catching middleware and, at the end of
the chain, into a 500 error that gets logged.

~~~
yamalight
The errors won't be swallowed only in two cases: either if router.get actually
supports promises (thus catches all the bubbled errors on its own) or if you
have unhandledRejection global listener. Some node versions do show unhandled
rejections automatically (e.g. v7.x), but that is getting deprecated soon.

So, there's quite a real risk of quiet failures in that bit of code.

Upd. Looks like even though the unhandled rejections warnings are getting
deprecated, the rejections themselves will actually stop the code execution
with non-zero exit code! Which means most of the issues I had with that code
are gone (which is awesome)

~~~
always_good
Of course the code in my example handles promises. It's actually an example of
koa code.

Not sure why that is a "real risk". You generally want to be using promises
with libraries that support them. That's why I wouldn't use promises in
vanilla Express as my daily driver abstraction.

Compare this to callbacks where there's an actual real risk of silent error
dropping any time you forget to `next(err)` or `.catch(handleErr)`, which is
something you have to carry around for the life of the project instead of my
example, where you choose a framework (once) that supports them.

I'd say it's a great demo and addressed all your concerns so far since it's
this kind of context where async/await really pays off compared to the
logFetch example.

~~~
tracker1
I really hope that this release means that koa2 will release soon.. been a
little painful to determine which versions of what modules are supported.
Really enjoying koa2 though.

~~~
always_good
You can keep track of the stable async/await-native koa release here:
[https://github.com/koajs/koa/issues/533](https://github.com/koajs/koa/issues/533)
(scroll to the bottom).

Looks like this is the release they've been waiting for.

~~~
tracker1
yeah, now I'm having trouble getting webpack + hmr working with koa2 in node
7.6... the webpack page mentions issues with v7, so trying what I had in v6,
will see if I can get it working.. :-(

------
brad0
> fs: allow WHATWG URL objects as paths (James M Snell)

Can someone explain this to me? Does this just mean I can open files using the
'file:' syntax or can I somehow open URLs with readFile now?

~~~
SlashmanX
The linked PR[0] says it's just using the file: syntax

[0] -
[https://github.com/nodejs/node/pull/10739](https://github.com/nodejs/node/pull/10739)

