I am creating a Node Project with Typescript and I have set the target option to es6 in tsconfig.json
Node version 8 supports the async/await syntax but Typescript converts that to a generator function
How can I tell typescript not to convert es6 features already present in Node?
async/await is supported in ES2017, so u may need to set your target in tsconfig.json to ES2017.
P.S. You may find meseret an interesting library to work with, if you're into TypeScript, async/await and Node.
Related
is it possible to use ES2020 in tsconfig instead of coomonjs in nodejs project. Because when I use commonjs typescript when compiled generates a lot of javascript.
ES2020 and commonjs pertain to different things when configuring your tsconfig.json
ES2020 will go in the lib array. It refers to which language features to include.
commonjs will go in the module property. This refers to which module system you are using (ie. are you using require and module.exports syntax (commonjs), or import and export syntax (esm)?).
I am migrating my code from commonJS to es6 as I have to upgrade my node version to 16+.
But, I got stuck here.
module.exports[path.parse(file).name] = sequelize.import(dir+'/'+path.parse(file).name);
I need to convert it to es6 syntax. Tried to google it, but couldn't find anything.
TypeScript's has a target configuration with many values, like esnext, es2015, es6 etc. (very confusing)
NodeJs current version (11.11.0) supports many of the new features of JavaScript. Is it ok to target esnext on TypeScript? will it work?
If not, what's the right target to use when targeting nodeJs 11.11.0
Edit:
Thanks to #Seblor we know that esnext is very dynamic and TC39 can add features as they see fit. It represents the next version of JavaScript that is being worked on (Regarding agreeing on features)
The refined question should be: According to the current version of NodeJs (11.11.0) and the current version of TypeScript (3.3) can we use esnext as the target?
Based on Node-Target Mapping on the TypeScript wiki "es2018" is the right mapping for Node 10, "es2019" is the right mapping for Node 12. It seems that non-LTS versions of Node aren't documented, but given this information I feel like "es2018" is the safest target.
Looking at node.green, ES2018 support seems to be full in Node 11.11.0, so you should be able to set ES2018 as target with no trouble.
You can push your luck by using ES2019 or even ESNext since the support looks good enough. However, I do not know if typescript will use non-yet-implemented features if you use ESNext as target (like the private properties).
Personally I would stick with ES2018, as I see no need to push for ESNext.
Ok so the answer is (As usual) Depends!
It depends on the features that you plan on using. The TypeScript version, target on the tsconfig.json and the NodeJS version.
There are two things to check before you can use a JavaScript feature:
You have to look at this table, and look at your target environment column, in my case it's NodeJs column. And make sure that the cell is Green. Red means that you can't run this feature on this environment.
Make sure that you can compile your code using TypeScript. If you can compile the code using TypeScript, you're ok. Note that you can NOT count on the TypeScript column. Red cell means that the compiled code will not run on previous version of JavaScript...
For example BigInt:
TypeScript with target: "esnext" will compile (With no problem) a code with bigint (While the support cell is Red), and you can run a JavaScript code with bigint on NodeJS 11
Note that on the top left, there's the ECMAScript version-group. you can go lower than esnext
Has anybody got a setup working in which module 1 using typescript is referencing another module 2 also with typescript and both use tsd types such as node.d.ts ?
I have no problem compiling both and using them, as long as i simply require module 2. But as soon as i use import instead, i get into duplicate identifier hell, due to the fact that source files in both modules import e.g. node.d.ts typings from obviously different paths. Classes in both projects use e.g 'streams' or 'lodash' thus both use them in typings and thus use the /// reference syntax. The tsconfig in both projects excludes typings.
Typescript has come a long way since this was asked, and it's now much easier. You can link the proper files in package.json:
{
"main": "library-commonjs.js",
"module": "library-es6-module.js",
"typings": "library-commonjs.d.ts"
}
main is used by packages using CommonJS and Node.js module resolution. module is used by packages supporting ES6 imports. And typings is followed by Typescript (currently Typescript 2.2) to resolve type definitions for the package.
After struggling with this, I spent some time creating a typescript boilerplate/starter project that demonstrates how to do it properly:
https://github.com/bitjson/typescript-starter
That project includes a lot more documentation, and several examples of how to import code from typescript projects.
EDIT: With TS 2.2 this has gotten quite a lot better. See the accepted answer.
It seems this is not really possible yet in typescript 1.8.x. But they seem to work on it via https://github.com/Microsoft/TypeScript/issues/7156.
Also the problem is supposedly mitigated by using a jsconfig.json which should be used by VScode (see https://blogs.msdn.microsoft.com/vscode/2015/07/06/visual-studio-code-es6/). Sadly i didnt get it working yet.
now that nodejs4 support classes and arrow functions, how do I tell typescript not to polyfill it?
now that nodejs4 support classes and arrow functions, how do I tell typescript not to polyfill it
You might think you can use target es6, but don't. E.g. the following in TypeScript :
function test(bar = 123){
}
Compiles to JavaScript with target es6:
function test(bar = 123) {
}
But default parameters aren't supported by node yet (reference)
Till the compatibility table of Node exceeds that of TypeScript ... be very careful! or just target es5.
Assuming you're using TypeScript now for node, you are likely specifying that your target output is ES5. Which means that it will polyfill/transpile ES6/7 features into the paradigm of ES5 in order to run in today's browsers and previous versions of node.
In order to use those features of ES6 today in node v4 you would just need to change your build process to output ES6 via the target option.
Note: this is true if you are using command line arguments or a tsconfig.json