typestrong / ts-node Goto Github PK

I spent a long time trying to resolve this already, but can't find a decent solution. I started based on https://github.com/babel/babel/blob/master/packages/babel/src/api/register/node.js with process.env.running_under_istanbul and got it executing but got stuck with no coverage information coming out.

Hello,

I tried to add my styles via require in my components like
require('./App.scss');

But I get this error:
SyntaxError: Unexpected token .
at exports.runInThisContext (vm.js:53:16)
at Module._compile (module.js:413:25)
at Object.Module._extensions..js (module.js:452:10)
at Module.load (module.js:355:32)
at Function.Module._load (module.js:310:12)
at Module.require (module.js:365:17)
at require (module.js:384:17)

Is there any chance I can mark them to exclude?

Currently, the arguments are all parsed instead of just up to the first filename. This can easily by fixed by first slicing the argv array and then evaluating it.

Some one pointed out they had run into this before, but didn't realise it wasn't just a REPL.

Let's see what can be done with microsoft/TypeScript#5140, otherwise let's think about it more.

Also relevant: http://flowtype.org/blog/2015/10/07/Version-0.17.0.html

Edit: https://github.com/Microsoft/TypeScript/blob/d5d7a2a2dc50e07d67547e81cde34c2e4d7c0bae/src/compiler/tsc.ts#L410

Sometimes you just want it to run.

The REPL would still need to use the language services API (to use .type, for example), but the execution environment can avoid it. It should be possible to create a program with the compiler options and write all the files into a tmp directory (or into memory?). When reading again (from node, this time) we check the modtime in the tmp directory vs the current file and either read from cache or re-compile using TypeScript and output diagnostics.

What's the downsides of either approach?

From #16.

VSCode will not recognize any breakpoints hit.

Thanks for amazing code!

Right now, if I do syntax error in mocha test itself (ex ./test/sometest.ts), mocha --watch will terminate due to https://github.com/TypeStrong/ts-node/blob/master/src/ts-node.ts#L198

Is this expected? Without ts-node mocha don't terminate on syntax errors in tests, it simply dumps stacktrace so programmer can fix an error and continue watch

It looks like we have to install typings now, so I did ("npm install -g typings"), but when I try to install ts-node I get the following:

2813 verbose stack Error: [email protected] postinstall: `typings install`
2813 verbose stack Exit status 1
2813 verbose stack     at EventEmitter.<anonymous> (C:\Program Files (x86)\nodejs\node_modules\npm\lib\utils\lifecycle.js:214:16)
2813 verbose stack     at emitTwo (events.js:87:13)
2813 verbose stack     at EventEmitter.emit (events.js:172:7)
2813 verbose stack     at ChildProcess.<anonymous> (C:\Program Files (x86)\nodejs\node_modules\npm\lib\utils\spawn.js:24:14)
2813 verbose stack     at emitTwo (events.js:87:13)
2813 verbose stack     at ChildProcess.emit (events.js:172:7)
2813 verbose stack     at maybeClose (internal/child_process.js:818:16)
2813 verbose stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:211:5)
2814 verbose pkgid [email protected]
2815 verbose cwd C:\updraft
2816 error Windows_NT 6.1.7601
2817 error argv "C:\\Program Files (x86)\\nodejs\\node.exe" "C:\\Program Files (x86)\\nodejs\\node_modules\\npm\\bin\\npm-cli.js" "install" "--save-dev" "ts-node"
2818 error node v4.1.2
2819 error npm  v2.14.4
2820 error code ELIFECYCLE
2821 error [email protected] postinstall: `typings install`
2821 error Exit status 1
2822 error Failed at the [email protected] postinstall script 'typings install'.
2822 error This is most likely a problem with the ts-node package,
2822 error not with npm itself.
2822 error Tell the author that this fails on your system:
2822 error     typings install
2822 error You can get their info via:
2822 error     npm owner ls ts-node
2822 error There is likely additional logging output above.
2823 verbose exit [ 1, true ]
2824 verbose unbuild node_modules\ts-node
2825 info preuninstall [email protected]
2826 info uninstall [email protected]
2827 verbose unbuild rmStuff [email protected] from C:\updraft\node_modules
2828 silly gentlyRm C:\updraft\node_modules\.bin\ts-node.cmd is being gently removed
2829 silly gentlyRm verifying C:\updraft is an npm working directory
2830 silly gentlyRm containing path C:\updraft is under npm's control, in C:\updraft
2831 silly gentlyRm deletion target C:\updraft\node_modules\.bin\ts-node.cmd is under C:\updraft
2832 verbose gentlyRm vacuuming from C:\updraft\node_modules\.bin\ts-node.cmd up to C:\updraft
2833 silly vacuum-fs removing C:\updraft\node_modules\.bin\ts-node.cmd
2834 silly vacuum-fs quitting because other entries in C:\updraft\node_modules\.bin
2835 silly gentlyRm C:\updraft\node_modules\.bin\ts-node is being gently removed
2836 silly gentlyRm verifying C:\updraft is an npm working directory
2837 silly gentlyRm containing path C:\updraft is under npm's control, in C:\updraft
2838 silly gentlyRm deletion target C:\updraft\node_modules\.bin\ts-node is under C:\updraft
2839 verbose gentlyRm vacuuming from C:\updraft\node_modules\.bin\ts-node up to C:\updraft
2840 silly vacuum-fs removing C:\updraft\node_modules\.bin\ts-node
2841 silly vacuum-fs quitting because other entries in C:\updraft\node_modules\.bin
2842 info postuninstall [email protected]
2843 silly gentlyRm C:\updraft\node_modules\ts-node is being purged from base C:\updraft
2844 verbose gentlyRm don't care about contents; nuking C:\updraft\node_modules\ts-node
2845 silly vacuum-fs purging C:\updraft\node_modules\ts-node
2846 silly vacuum-fs quitting because other entries in C:\updraft\node_modules

it would be great if ts-node had browser field support
https://github.com/defunctzombie/package-browser-field-spec

The command line interface is ts-node, which is inconsistent with the package name. Should I make the CLI longer (unlikely, too much to type), rename the package for consistency or ignore it?

I've tried to use this module as mocha --compilers tsx:typescript-node/register and it works great, but when I add --watch, it will always run the same code as the first run of mocha. I suspect it's caching the compiled files and not recompiling until running again.

I'm using it with typescript@next (1.6.0-dev.20150908) and .tsx files (for JSX support).

When I was using babel compiler for my js tests, --compilers js:babel/register, was working fine.

I'm trying to switch over to the latest typescript so that I can use async/await inside a mocha test. My tsconfig specifies es6 and module commonjs. If I run tsc from the command-line it reports no errors, but when I run from gulp (which registers ts-node) I get this error.

[15:15:17] Using gulpfile C:\updraft\Gulpfile.js
[15:15:17] Starting 'test'...
[15:15:20] 'test' errored after 3.03 s
[15:15:20] SyntaxError in plugin 'gulp-mocha'
Message:
    Block-scoped declarations (let, const, function, class) not yet supported outside strict mode Stack:
SyntaxError: Block-scoped declarations (let, const, function, class) not yet supported outside strict mode
    at exports.runInThisContext (vm.js:53:16)
    at Module._compile (module.js:413:25)
    at Object.loader (C:\updraft\node_modules\ts-node\dist\ts-node.js:102:18)
    at Module.load (module.js:355:32)
    at Function.Module._load (module.js:310:12)
    at Module.require (module.js:365:17)
    at require (module.js:384:17)
    at Object.<anonymous> (C:\updraft\src\index.ts:1:20)
    at Module._compile (module.js:434:26)
    at Object.loader (C:\updraft\node_modules\ts-node\dist\ts-node.js:102:18)

So problem (1) is that there shouldn't be a difference between tsc and ts-node (I have typescript@next installed locally and globally), and (2) is that the output gives no indication of where (file/line) the error was found

From #24. Should also clarify that certain issues are coming from node and that this always loads tsconfig.json by default - how to use two tsconfig.json files.

I have the following files;

MyClass.ts

class MyClass {
    x: number;
    y: number;
    constructor(x: number, y :number) {
        this.x = x;
        this.y = y;
    }
}

MyScript.ts

/// <reference path="MyClass.ts" />
var myClass: MyClass = new MyClass(2,3);
console.log(myClass.x, myClass.y);

Compiling via tsc is successful, however I cannot execute MyScript.cs with ts-node. Am I doing something wrong?

c:\git\ts-node-test>tsc MyScript.ts

c:\git\ts-node-test>ts-node -v
0.5.5

c:\git\ts-node-test>ts-node MyScript.js

c:\Users\stafford\Documents\git\ts-node-test\MyScript.js:2
var myClass = new MyClass(2, 3);
                  ^
ReferenceError: MyClass is not defined
    at Object.<anonymous> (c:\Users\stafford\Documents\git\ts-node-test\MyScript.js:2:19)
    at Module._compile (module.js:398:26)
    at Object.Module._extensions..js (module.js:405:10)
    at Module.load (module.js:344:32)
    at Function.Module._load (module.js:301:12)
    at Function.Module.runMain (module.js:430:10)
    at Object.<anonymous> (C:\Users\stafford\AppData\Roaming\npm\node_modules\ts-node\src\bin\ts-node.ts:121:12)
    at Module._compile (module.js:398:26)
    at Object.Module._extensions..js (module.js:405:10)
    at Module.load (module.js:344:32)

c:\git\ts-node-test>

Repro

When compiling TypeScript at runtime or in the REPL, or even in the CLI, there's no need to throw errors with a stack trace. The errors could also use some colour with the output to easily identify issues.

Makes the CLI more consistent with that of TypeScript's CLI. Sets the location to start resolving tsconfig.json from.

Thanks for writing ts-node for TypeScript register!

Hi, I'm writing browser mock test in jsdom.
The source code relies heavily on DOM and BOM, so I opted jsdom-global for better import behavior.

Both my source code and test code are written in TypeScript. And I use ts-node for ts extension register.

However, it seems jsdom-global breaks ts-node (or vice-versa). Something wrong with sourcemap.

Minimal setup:

npm install mocha ts-node jsdom jsdom-global
tsd install mocha node

Test code:

/// <reference path='../typings/tsd.d.ts' />

import * as assert from 'assert'
// import jsdom from 'jsdom-global'
var jsdom = require('jsdom-global')
jsdom()

describe('test sourcemap', () => {
    it('should report sourcemap', () => {
        assert(false)
    })
})

> mocha --compilers ts:ts-node/register
/tmp/node_modules/source-map-support/source-map-support.js:407
      var hasStack = (arguments[1] && arguments[1].stack);
TypeError: Invalid URL
npm ERR! Test failed.  See above for more details.

And when I changed the compiler to babel (and test file extension to js). Error is reported as expected.

> mocha --compilers js:babel-register



  test sourcemap
    1) should report sourcemap


  0 passing (46ms)
  1 failing

  1) test sourcemap should report sourcemap:

      AssertionError: false == true
      + expected - actual

      -false
      +true

      at Context.<anonymous> (index.js:10:3)

In ts-node.ts around line 80,

  config.compilerOptions = extend({
    target: 'es5',
    module: 'commonjs'
  }, config.compilerOptions, {
    sourceMap: true,
    inlineSourceMap: false,
    inlineSources: false,
    declaration: false
  })

should be

  config.compilerOptions = extend({
    sourceMap: true,
    inlineSourceMap: false,
    inlineSources: false,
    declaration: false
  }, config.compilerOptions, {
    target: 'es5',
    module: 'commonjs'
  })

for { target: 'es5', module: 'commonjs' } to take precedence over user's options, which potentially may be intended for latest browsers environments.

I'm getting this error right now when I use destructuring in my typescript code:

SyntaxError: Unexpected token [

Otherwise, it has been great.

First off, thanks for creating and maintaining ts-node. It is awesome!

Consider the following Node script args.js:

console.log(process.argv)

Calling this with node, we get the following result:

>node args hi -- test -a
[ 'C:\\Program Files\\nodejs\\node.exe',
  'C:\\temp\\args',
  'hi',
  '--',
  'test',
  '-a' ]

But if you call it using ts-node, you lose the -- argument:

>ts-node args hi -- test -a
[ 'node', 'C:\\temp\\args', 'hi', 'test', '-a' ]

I came across this when trying to use yargs to parse command line arguments. yargs considers the -- argument as a signal to stop parsing arguments and take the rest of the arguments as string literals rather than switches. When running it through ts-node, the -- disappears, so arguments that should be taken literally are being parsed as switches. I can overcome this by passing -- --, but I think it would be better to have a consistent behavior between node and ts-node for interoperability.

For example, echo "'hello world'" | ts-node. This is supported by node.

Error token "..." but not error compile by tsc

SyntaxError: Unexpected token ...
at exports.runInThisContext (vm.js:53:16)
at Module._compile (module.js:374:25)
at Object.loader (D:\project\node_modules\ts-node\src\ts-node.ts:225:14)
at Module.load (module.js:344:32)
at Function.Module._load (module.js:301:12)
at Module.require (module.js:354:17)
at require (internal/module.js:12:17)
....

tsconfig.ts

"compilerOptions": {
"target": "es5",
"jsx": "react",
"module": "commonjs"
}

environment
typescript: 1.8.2
ts-node: 0.5.5

I am using typescript@next and got following error:

/Developer/Work/node/koa-router-decorators/node_modules/ts-node/dist/ts-node.js:32
    return ts.parseConfigFile(config, ts.sys, fileName);
              ^

TypeError: ts.parseConfigFile is not a function
    at readConfig (/Developer/Work/node/koa-router-decorators/node_modules/ts-node/dist/ts-node.js:32:15)
    at Object.register (/Developer/Work/node/koa-router-decorators/node_modules/ts-node/dist/ts-node.js:41:18)
    at Object.<anonymous> (/Developer/Work/node/koa-router-decorators/node_modules/ts-node/register.js:1:77)
    at Module._compile (module.js:435:26)
    at Object.Module._extensions..js (module.js:442:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:311:12)
    at Module.require (module.js:366:17)
    at require (module.js:385:17)
    at /Developer/Work/node/koa-router-decorators/node_modules/mocha/bin/_mocha:296:3
    at Array.forEach (native)
    at Object.<anonymous> (/Developer/Work/node/koa-router-decorators/node_modules/mocha/bin/_mocha:290:19)
    at Module._compile (module.js:435:26)
    at Object.Module._extensions..js (module.js:442:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:311:12)
    at Function.Module.runMain (module.js:467:10)
    at startup (node.js:134:18)
    at node.js:961:3

From #27 (comment), allow compiler options to be passed in from via CLI + API.

Currently each REPL line replaces the previous and all type information is lost. Not very useful at all. First thoughts are to concat each line and pass it through the TypeScript compiler, then using diff to execute the new code paths.

Related to #1, it'd be great to have tab autocomplete with documentation.

From the issues I've seen logged thus far, I'm looking at rewriting ts-node into something that can suit more people. Here's some of the points that need covering for 1.0. Comments are appreciated.

• The goal is to be fast and production-ready out of the box (breaking change)
  • This means no type information, because that requires loading the entire project into memory
  • All files will transpile directly, in-memory using TypeScript transpileModule
  • Can enable a cache directory for a simple speed up
• One level up, semi-production ready, is the --typed flag
  • This transpiles the entire project and caches it once on startup
  • This has type information, but only for things in the initial project/require - subsequent requires of TypeScript files would fall back to the first point
• The next level, non production ready, is the --fully-typed flag
  • This is basically the current version of ts-node, suitable for a test suite
  • Everything needs to be in-memory because require can be "out-of-band". E.g. .ts -> .js -> .ts, not possible to handle by just the TypeScript compiler
  • We can think about way to fix this "out of band" require issue, but I believe changed files should always be re-loaded correctly (E.g. watching a test suite should get new diagnostics without re-compiling everything) /cc @basarat Any thoughts on this point? Maybe a way to serialize the compiler state in some form?
• The project flag is disabled by default (still considering this)
  • Enable ability to specify directory or file
• Compiler option flag - specify TypeScript compiler options via JSON
• All flags should have an environment variable for environments that can't specific CLI flags - E.g. Gulp, Grunt, etc.

I'm getting an error

[10:28:53] Requiring external module ts-node/register

    project/node_modules/ts-node/dist/ts-node.js:68
            var result = output.outputFiles[1].text;
                                              ^
    TypeError: Cannot read property 'text' of undefined
        at getOutput (project/node_modules/ts-node/dist/ts-node.js:68:43)
        at compile (project/node_modules/ts-node/dist/ts-node.js:91:16)
        at Object.loader (project/node_modules/ts-node/dist/ts-node.js:94:27)
        at Module.load (module.js:355:32)
        at Function.Module._load (module.js:310:12)
        at Module.require (module.js:365:17)
        at require (module.js:384:17)
        at Liftoff.handleArguments (project/node_modules/gulp/bin/gulp.js:116:3)
        at Liftoff.<anonymous> (project/node_modules/gulp/node_modules/liftoff/index.js:192:16)
        at module.exports (project/node_modules/gulp/node_modules/liftoff/node_modules/flagged-respawn/index.js:17:3)

I've made a snapshot of the project here alexgorbatchev/gulp-typescript-webpack-react-hotreload@d6fc57f . Try running gulp dev.

Since the module could end up being used in a lot of different environments (E.g. gulp), there should be a way to configure it via config file or environment. Since tsconfig.json already exists, I'd say we piggy back off it and add a typescript-node property to the object.

Hi again :)

I noticed some weird behavior while running some tests on travis. It seems that the exclude property in tsconfig.json is sometimes not honored.

This here is the failing test on travis. You can see that it complains about duplicate typings, although jspm_packages is excluded in the tsconfig.json. Also, this test here passes without any errors although they are both run from the same codebase.

Is this a bug or do I have a faulty configuration?

https://github.com/TypeStrong/ts-loader/blob/master/.travis.yml#L8-L11

Hi,
I have a question: is it possible to use ts-node/register followed by babel-core/register?

My goal is to have typescript configured to output es6, and then have babel do the es6 to es5 conversion. Thus, I would be able to use typescript interfaces where needed, but still integrate with other parts of the code using ES6 javascript.

Putting the two requires in my index.js does not raise any error, but also does not have the intended behaviour - I get different outputs if I just run node index.js, or if I manually run tsc first and then run node index.js - the difference being, IMHO, that the second case passes the js files outputed by the typescript compiler through babel, while the first case doesn't.

For reference:

index.js

require('babel-core/register');
require('ts-node/register'); 
require('./Tasks');

tsconfig.json

{
    "compilerOptions": {
        "target":"es6"
    },
    "files": 
        ["Databases.ts"
        ,"Tasks.ts"
        ]
}

Hi there,

when using ts-node/register via interpret on .ts files, AND using noEmit:true in tsconfig.json, it works just fine for typescript 1.7.3., but gives an error for typescript 1.8.0:

Requiring external module ts-node/register

⨯ Unable to compile TypeScript

gulpfile.ts: Emit skipped

It would be nice if we could get this to work again, because otherwise I can't get my IDE to shut-up (= not compile files, that I want my gulp to produce instead).

Hi!

I love ts-node so far but I run into issues when I want to run multiple tests at once. You can check out a sample repository to reproduce the error.

I have three tests and two test scripts declared in package.json. When I run

npm run test-single

# test-single: mocha test/test.ts --require ts-node/register && mocha test/test3.ts --require ts-node/register && mocha test/newtest.ts --require ts-node/register

it will execute each test one by one and everything seems to work fine. However, if I run all tests within one mocha run, like

npm test

# test: mocha test/**/*.ts --require ts-node/register

I receive the following TypeScript compilation errors from ts-node:

> [email protected] test /usr/local/src/Misc/ts-node-mocha
> mocha test/**/*.ts --require ts-node/register

----------------------------------
⨯ Unable to compile TypeScript

test/newtest.ts (5,14): Property 'should' does not exist on type 'string'. (2339)
test/test.ts (5,14): Property 'should' does not exist on type 'string'. (2339)
typings/should/should.d.ts (125,12): Cannot find name 'should'. (2304)
----------------------------------
npm ERR! Test failed.  See above for more details.

What am I doing wrong? I'd really like to test all files within a folder at once.

I've been looking at #44 and I noticed that one of the things you want to do is make it fast and production-ready. I'm really excited about this, but I realize that a lot of time is involved in a rewrite and that I can't realistically expect this to be done in the near future (although I'd be happy to help).

I'm working on a tool called node-script (https://github.com/joeskeen/node-script), which allows you to create self-contained Node scripts (not requiring a package.json file or running npm install first). One of the big things I'm in the process of tackling before v1.0 is transpiler support. I'm currently using the interpret module to determine which packages are required to register the script file. Currently ts-node is first in line for the ts file extension, so that is the one that node-script calls upon to run TypeScript node-scripts. The issue comes when I copy the script file to another location to run it in isolation. Removed from its home during development, the script's /// <reference /> comments and other typing resolution no longer resolves. Since interpret points me directly to require('ts-node/register'), I can't call require('ts-node').register({options}) without making a special case.

If ts-node's register function was able to pick up whether to disableWarnings from process.env or something similar, I could make sure that that is set before require('ts-node/register') is called.

I think that this could be a good workaround until the new production-ready version of ts-node is ready.

Sometimes you want to just run something, while still displaying the warnings (e.g., missing type definitions) that you should fix once that your implementation is working.

It's possible to be in an environment where you don't have access to setting startup options. E.g. Gulp. This would allow the user to set them in the environment before running - TS_NODE_NO_PROJECT=true gulp.

Should be able to enable things like --harmony from ts-node --harmony script.ts. Good place to start: https://github.com/babel/babel/blob/master/packages/babel-cli/src/babel-node.js

In order to use ES6 features but compile down to ES5 I am using the following config options in tsconfig.json:

compilerOptions: {
   target: 'es5',
   noLib: true,
},
files: [
  'node_modules/typescript/lib/lib.es6.d.ts',
   ...
]

however this causes loads of 'duplicate identifier' compiler errors because ts-node is not observing the noLib option here

For some reason command line ts-node seems to search the local node_modules folder even when there are no references to it in the file you run. Also, if I run ts-node to get a REPL and execute any command inside a project that has typescript in it, but also have typescript installed globally, I get thousands of duplicate identifier errors.

If I remove typescript from the local project, I get node_modules/autoprefixer-loader/node_modules/postcss/postcss.d.ts (2,22): Cannot find module 'd.ts/postcss'. (2307) node_modules/autoprefixer-loader/node_modules/postcss/postcss.d.ts (3,2): Duplicate identifier 'default'. (2300)

so it appears to search my node_modules folder for all kinds of definitions and then throw a bunch of errors before it evaluates the first line of typescript. I get the same errors running an empty typescript file. Is this expected behavior?

Would be awesome to be able to use ts-node as a shebang script:

#!/usr/bin/env ts-node
console.log('ohai from TypeScript');

Hi, wondering what version of Typescript is currently supported?

Are there known performance issues of ts-node? I have a medium sized typescript project and we used to compile with tsc and then run tests with mocha. However, ts-node seems to be better because we a) don't need to have a plugin to support sourcemaps and b) generate js and js.map files before we run the tests. So I tried ts-node with mocha in gulp but now builds take ~20s. I suspect that this is because all the files have to be recompiled. Is this a known issue?

Hi,

I'm trying to test a generator project and I'm receiving errors when my gulpfiles are written in TypeScript.

You can look at the logs of the tests on Travis. It fails to load the ts-node/register module to parse the gulpfile.ts.

Everything seems to work fine on node 5 and higher but it fails to load the ts-node/register module on node versions below that. On my local machine (node v4.2.1) everything works fine.

Do you know what the reason could be? I'm trying to run the following testfile.

I'm using ts-node to get gulpfile.ts to work and it appears that ts-node compiles all TypeScript files when gulp starts. If I have errors in clientside files that aren't required anywhere in the gulpfile.ts file, gulp still fails to start because ts-node fails with TypeScript errors.

I have my clientside files linked in tsconfig.json, which might be causing this side effect. I'm worried that eventually when the project gets larger it will become a real problem because ts-node will unnecessarily compile all TypeScript files.

Node appears to handle this by detecting syntax errors. I can probably catch compilation errors and check the error codes are syntax errors too and recover from that.

Relevant: https://github.com/joyent/node/blob/d13d7f74d794340ac5e126cfb4ce507fe0f803d5/lib/repl.js#L125-L129

Hi, I cannot use default parameter

// hello.ts
function hello(name = 'World') {
    console.log(`Hello, ${name}`)
}

$ ts-node hello.ts
SyntaxError: Unexpected token =
    at exports.runInThisContext (vm.js:53:16)
    at Module._compile (module.js:374:25)
    at Object.loader (/sandbox/node_modules/ts-node/src/ts-node.ts:225:14)
    at Module.load (module.js:344:32)
    at Function.Module._load (module.js:301:12)
    at Function.Module.runMain (module.js:430:10)
    at Object.<anonymous> (/sandbox/node_modules/ts-node/src/bin/ts-node.ts:121:12)
    at Module._compile (module.js:398:26)
    at Object.Module._extensions..js (module.js:405:10)
    at Module.load (module.js:344:32)

below code works fine

function hello(name) {
    console.log(`Hello, ${name}`)
}

environment

• node: 5.4.0
• typescript: 1.7.5
• tsconfig.json

{
    "compilerOptions": {
        "target": "es6",
        "noImplicitAny": false,
        "sourceMap": false
    },
    "exclude": [ "node_modules" ]
}

thanks.

/Users/aolson/Developer/updraft/node_modules/ts-node/dist/ts-node.js:32
    return ts.parseConfigFile(config, ts.sys, fileName);
              ^

TypeError: ts.parseConfigFile is not a function
    at readConfig (/Users/aolson/Developer/updraft/node_modules/ts-node/dist/ts-node.js:32:15)
    at Object.register (/Users/aolson/Developer/updraft/node_modules/ts-node/dist/ts-node.js:41:18)
    at Object.<anonymous> (/Users/aolson/Developer/updraft/Gulpfile.js:55:20)
    at Module._compile (module.js:434:26)
    at Object.Module._extensions..js (module.js:452:10)
    at Module.load (module.js:355:32)
    at Function.Module._load (module.js:310:12)
    at Module.require (module.js:365:17)
    at require (module.js:384:17)
    at Liftoff.handleArguments (/usr/local/lib/node_modules/gulp/bin/gulp.js:116:3)

looks like they renamed parseConfigFile to parseJsonConfigFileContent