
Node v8.1.2 - janober
https://nodejs.org/en/blog/release/v8.1.2
======
Maarten88
I upgraded a universal React/typescript project from node 6.10 to 8.1 this
week. Configured typescript compilation in webpack to target es2017 server-
side and es5 client-side. It worked flawlessly.

Debugging async functions (server-side) is a lot better now that there is no
transpiler mangling my code beyond recognition.

~~~
doomslice
Would you mind sharing your tsconfig(s)? And also do you use sourcemaps on the
server?

~~~
Maarten88
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

~~~
devrelm
Looking at "paths", shouldn't those @types (history, redux & react) be picked
up automatically, at least as of TypeScript 2.0?

Also:

    
    
      "*": [ "./ClientApp/types/*", "*" ]
    

I like that. I may have to add it to my app and get rid of our typings.d.ts
(currently included through "files") once and for all.

~~~
Maarten88
They were there to fix "Duplicate identifier" errors caused by multiple
dependencies fetching their own copies of type definitions.

But you are right: typescript or those dependencies have improved and they are
no longer necessary. I removed them and everything still works.

------
libertymcateer
Now's as good a time as any to ask:

What tools do you folks use to monitor your node dependencies and make sure
you are keeping everything up to date?

~~~
workerIbe
Definitely something to the addage "if it ain't broke don't fix it". Some of
our less critical modules are set to latest others are updated with care. Our
modules are not under source control so are refreshed on deployment. We use
Snyk to monitor for vulnerabilities, works pretty well.

~~~
allover
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)!

~~~
rubber_duck
This so much - shrinkwrap before it bites you when a CI kicks off a deploy
that fails because it pulled latest minor dep release that broke everything
(happened even in big lib like Angular 2 for us after stable 2.2 !) while your
local box is running fine with a cached older version.

------
ihsw2
Node 8 is the planned LTS release for later this year.

Notably, it brings async/await syntax to vanilla JS. This new feature
complements callbacks and largely replaces how Promises are currently consumed
(opting for sequential-like execution with try/catch blocks instead of Promise
chains).

The closest analogue would be Tasks in C#.

EDIT: removing reference to node-v8 to prevent confusion.

~~~
pier25
Aync/await is the best thing since sliced bread. It has made my life so much
easier.

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

~~~
cloverich
Sounds interesting -- do you have any resources handy that cover what you
allude to (spec. comparing async calls to promises, and favoring the latter?)
I use both in my ui code and they seem to have their niche for me. I prefer
promise based calls when I want to separate out fetching data from the state-
mutating callback, or when I may want to "cancel" something (ex: fetch a list
of items for a list component, then unmount the component before the list
returns -- no need to handle the response data anymore).

~~~
davidgf
Unfortunately not, my opinion is simply based on my personal experience and on
what I've been learning along the way. I find promises really handy for data
processing pipelines (grab some data and perform some transformations over it
to get it in the form you need), regardless of wether any of the steps is
async or not. I still find async/await really useful and mix it with promises
if I need it, but I prefer to keep my code as functional as I can. Besides, I
don't really like how JavaScript handles exceptions and would rather staying
away from try/catch if possible

