Node v8.1.2

This is my tsconfig.server.json:

   {
      "files": [],
      "compilerOptions": {
        "baseUrl": ".",
        "moduleResolution": "node",
        "target": "es2017",
        "jsx": "react",
        "experimentalDecorators": true,
        "sourceMap": true,
        "skipDefaultLibCheck": true,
        "lib": [ "es2017", "dom" ],
        "allowJs": false,
        "paths": {
          "*": [ "./ClientApp/types/*", "*" ]
        }
      },
      "exclude": [
        "bin",
        "obj",
        "node_modules"
      ]
    }

edit: remove unneeded entries

But in addition to that, how do you "update all and bump relevant package.json entries, dependencies _and_ devDependencies as appropriate" ?

`npm update --save` or `npm update --save-dev` say explicitly "save updates to `dependencies` resp. `devDependencies`", which causes duplication between dependencies and devDependencies. (Say you have a dep foo and a devDep bar and both are outdated: `npm update --save` will bork package.json with an additional incorrect dep bar, and `npm update --save-dev` will bork it with an additional incorrect devDep foo :-/ )

Am I missing something? I understand there are 3rd-party packages providing such functionality, but is there any reason to not cover this feature in npm?

Are you at least checking in your npm-shrinkwrap.json? (If not you've got pain waiting to happen, that you won't find out about until deploy time)!

But instead they created confusion on how to write the node version number :)

If the goal was to avoid confusion, it was an incredibly dumb decision. I'll continue referring its standard version number: Node v8.

Agreed! once you start using it there's no going back (along with `util.promisify`)

I started using Async/Await and liked it, but I've been learning more about functional programming and went back to Promises

I understand the reasons why async/await is designed the way it is, but I still think it is backwards. Really if you wanted to truly make async programming approachable, you should make it transparent. What I mean by this is that instead of marking a function as async, and awaiting values, you'd mark lines as async, opting out of implicit awaits. I wrote up some thoughts on this here:

https://github.com/utilise/emitterify/issues/1#issuecomment-...

The way it is now, I defensively await things all over the place. What's worse, it propagates. If any of your function's dependencies are async, your function will also have to be async (or be ok with continuing operation after it's returned) and it turtles all the way down.

It is nicer than having to deal with promises directly though, there is that.

They dropped the "v" from the version name.

Yeah, a lot of companies won't touch non-LTS Node though, so a lot of users won't use async/await until later this year when the next LTS is released (Oct 2017).

You do realize that implementing promises is a prerequisite for async/await, right?

You do realise that async/await is basically syntactic sugar for promises in JS, don't you?

How would you propose that async/await work without Promises? Even C#'s async/await uses the same concept: https://msdn.microsoft.com/en-us/library/system.threading.ta...

Pending the implementation of new language syntax, raw Promises were a practical solution for what they set out to accomplish. If you don't think they improved callback hell at all, I expect that you probably weren't using them correctly (an easy mistake to make without looking at the documentation and/or reading the wrong tutorials / blog posts).

cf.

    getAsyncValue1(a =>
        getAsyncValue2(a, b =>
            getAsyncValue3(b, c =>
                doSomething(c)
            )
        )
    );

and

    getAsyncValue1().then(a =>
        getAsyncValue2(a)
    ).then(b =>
        getAsyncValue3(b)
    ).then(c =>
        doSomething(c)
    );

Sure, async/await flattens that to zero nested callbacks, which is great, but with that off the table I'd rather deal with code flattened to one level deep (or a few, in some edge cases) than arbitrarily many. And that's just the "callback hell" improvement; don't forget what a nightmare error handling with callbacks can be — you have to handle both synchronous exceptions and error value callback parameters, you have to deal with the possibility of the asynchronous function unexpectedly calling your callback more than once, etc.