Incorrect order of extend()ing compilerOptions about ts-node HOT 7 CLOSED

@terasaka2k This is correct. The sourceMap options need to override the user settings, there's specially handling for it. The user, however, could output ES6 or ES3 if they so wished. Same with the module environment.

Edit: Accidentally hit enter.

from ts-node.

Consider this use case: I'm using webpack to chain the typescript-loader and the babel-loader together to take advantage of babel's hook runtime for things like HMR. I want my tsconfig.json to target ES6 and let the babel-loader transpile from ES6 to ES5 for browsers.

However, in my server code, I want to go straight from TS to ES5. I would like to be able to do this:

# index.js - server entry point
require('ts-node').register({
    compilerOptions: {
        target: 'es5'
    }
})

And then what I would expect to happen in ts-node would be something like:

const defaultConfig = { target: 'es5', module: 'commonjs' };
const tsConfigFromFile = readFromTsConfigJson();
Object.assign({}, defaultConfig, tsConfigFromFile, tsConfigFromArgs)

from ts-node.

@darthtrevino I'm not sure who you're responding to, but that's how it works already and the reason I closed the issue. However, there's no compilerOptions pass in to ts-node, it's all from tsconfig.json.

from ts-node.

It sounds like you're actually after a different feature? The ability to pass in compiler options that override tsconfig.json?

from ts-node.

Correct

from ts-node.

@darthtrevino #54

from ts-node.

Sweet! Thanks @blakeembrey !

from ts-node.