ts-node suggests to use require('ts-node/register'). And this can be seen in angular2-webpack-starter Protractor configuration.
What is require('ts-node/register') supposed to do? Does it patch require to transpile TS files, so a part of Node.js application could be written in TypeScript?
It does what you think it does. require('ts-node/register') is actually the same as:
require('./').register({
lazy: true
})
See examples here: https://github.com/TypeStrong/ts-node/tree/master/register
The .register function registers the Typescript compiler for files with .ts and .tsx extension for compilation on the fly.
Related
I'm currently rewriting a NodeJS project from a messy combination of CommonJS and Babel-transpiled ES Modules to be completely ES Module based.
In the process, I've become a bit confused by how Node handles these things. I've tried to read up on it, but I seem to be missing one final piece in my understanding.
I was assuming I would no longer need to use Babel to transpile the ES Modules. This seems to be correct. However, when I run my (Jest) tests, I still need to use the --experimental-vm-modules Node flag to make everything work.
My question is: what does that flag do? Reading the documentation, this seems to enable ES Modules, but didn't I already enable ES Modules by specifying "type": "module" in the package.json file?
Relevant links:
https://nodejs.org/api/esm.html#enabling
https://nodejs.org/api/cli.html#--experimental-vm-modules
https://jestjs.io/docs/ecmascript-modules
Specifying type: "module" in package.json just telling library authors your source code is based on ESM.
For jest, you need to use experimental-vm-modules because the node api jest uses to enable ESM support is still not stable as of node 18.x
https://jestjs.io/docs/ecmascript-modules
My question is not about why something is not working, but rather why it is. Yes.
I have a small nodeJS command line tool, which contains features that nodeJS does not yet support out of the box, most notably:
import statements
String.includes().
Thus for delivery(build) I transpile+bundle my source code (using parcel, just like webpack).
As a positive wonder, all (but one) of my mocha tests run directly against my classes, not the bundle. Still, they work! Including many import statements. And including an 'ES6 self-test':
it( 'String - include', () => {
var s = 'Southern Bananas'
assert( s.includes( 'anana' ) )
assert( !s.includes( 'kiwi' ) )
} )
Thus:
I have String.include in my test code, not just in the source under test. And there is no place where I transpile or bundle my test code… Thus apologies for my dumb question:
Why is this working? Is there a secret just-in-time compilation somewhere? (and if yes, could I use that for a debug flavour of my deliverable code-under-test as well?)
my mocha.opts are rather simple:
--require #babel/register
--require ./test/once.js (nothing special here, either)
--reporter list
--recursive
my .babelrc has this:
{
"presets": [
[
"#babel/preset-env",
{
"targets": {
"Electron": "3.0",
"Node": "8.0"
}
}
]
],
"plugins": [
"#babel/plugin-transform-runtime"
],
"retainLines": true,
"comments": false,
"sourceMaps": true
}
#babel/plugin-transform-runtime is apparently not to blame praise, as it explicitly states
NOTE: Instance methods such as "foobar".includes("foo")
will not work since that would require modification of
existing built-ins (you can use #babel/polyfill for that).
Is #babel/polyfill contained in the minimalistik-modern afaik #babel/preset-env? What else an I doing right :+)? Is there a way to use this live compilation for my (debug) build as well?
Long story short
String.prototype.includes is supported by Node.js since v6.5. #babel/register is causing your code to be compiled on the fly, that's why your import statements work. I doubt you need the #babel/plugin-transform-runtime plugin, unless I'm missing something that you're trying to achieve.
What can cause this confusion?
I think there are two root causes to this (totally understandable) mystery:
The Babel authors have made it really easy to use the tool; and sometimes it is hard to know how/when it is being invoked (especially when paired with another tool like Mocha).
What is/isn't supported natively by Node.js (in terms of ES2015, ES2016, etc.) has traditionally been hard to keep up with.
So, on to the two mysteries.
Why does String.prototype.includes work?
This one has the easier explanation. String.prototype.includes has been supported natively since as early as Node.js v6.5 (as you can see, a vast majority of ES2015 support has been supported since that version).
So, while you're correct that you don't have #babel/polyfill configured (as far as I can tell) and that you would need it in an environment that doesn't support String.prototype.includes, your environment already supports it!
From a Node.js v8.x REPL:
> 'ES2015'.includes('2015')
true
Why does your import statement work?
As you've stated, Node.js v8.x does not natively support ECMAScript Modules. However, there are some good write ups about how it has been enabled as an experimental feature starting in Node.js v9.x.
So, you get the following with native Node.js v8.x (via REPL):
> import path from 'path';
import path from 'path';
^^^^^^
SyntaxError: Unexpected token import
The reason your imports are working is because your code is being compiled by Babel using the #babel/preset-env preset. Furthermore, that compilation is being triggered by your --require #babel/register Mocha option.
#babel/register works by "bind[ing] itself to node's require and automatically compile files on the fly".
Here is a basic example of #babel/register in action:
From the command line:
$ node main.js
You will see this, because there is no syntax error!
main.js
require('#babel/register');
// This next file is compiled on the fly
require('./file1.js');
file1.js
import path from 'path';
console.log('You will see this, because there is no syntax error!');
The good thing is, this is how Mocha recommends you integrate Babel in their documentation. The --require option basically does what the above example does: require('#babel/register'); is called before Mocha uses require to import all of your test files.
Hope this helps! Again, this is a totally understandable mystery in the modern age of rapidly-evolving JavaScript.
I am using koa framework of node.js. I have implemented my code using typescript. I have created .ts files for the same and I am using tsc compiler to compile it.
Should I use babel or tsc for compiling the code?
Before sometime, I read about babel. Now, I have a doubt wheather to use babel or tsc for compiling the code. Please suggest.
Both are excellent choices.
Babel: Main focus is transpiler
TypeScript: In addition to be a transpiler main focus is a type checker.
Opinion
I prefer TypeScript for reasons covered here 🌹
I'm using WebStorm to build a Node.js app in TypeScript. When I write a "require" statement, the TypeScript compiler uses AMD. I know it by the js output with the asynchronous pattern.
How can I tell WebStorm to use CommonJS instead?
I'm not a WebStorm user myself, but I think WebStorm refers to the tsconfig.json file at the root of your TypeScript project for this type of compiler configuration.
Here's the documentation for the tsconfig.json file.
If this file doesn't already exist in your project, create one in the root of your TypeScript compilation directory. In this file, you can tell the compiler which module system to use with the module parameter:
{
"compilerOptions": {
"module": "commonjs"
}
}
See the link above for a more complete example of a tsconfig.json file.
You have to say that to compiler, for example in npm
Option:
-m, --module Specify module code generation: 'commonjs' or 'amd'
Example:
tsc.compile(['test/cases/ship.ts', 'test/cases/fleet.ts'],
'-m commonjs -t ES5 --out test/tmp/navy.js');
for more refer to: TypeScript compiler
also have a look at this video: TypeScript Modules Demystified : Internal, AMD with RequireJS, CommonJS with NodeJS
Problem
I have a reasonable amount of experience using Babel in my projects, but I've come across a situation which I am not sure about:
I have an es5 project, which has a dependency of an es7 node module (a deployment tool).
I want the es5 project to use the es7 module without "polluting" the es5 project with Babel infrastructure.
If my deployment tool module only used es6, I could include the es6 polyfill.
But as there is not es7 polyfill it looks like i should be using [plugins] (https://www.npmjs.com/package/babel-plugin-array-includes).
EDIT #1: As an analogy: If I was using coffeescript, I'd just transpile and save the output in my-coffee-module/dist/index.min.js. How could I do the same with Babel?
I'd perfer to not use the CLI, or another tool (like rollupjs - which is good, but it seems unnecessary).
Previous work
When I put a .babelrc in my module (or use the require hook):
require("babel-core").transform("code", {
presets: ['babel-preset-es2015'],
plugins: ["array-includes"]
});
and then use it from my es5 project I get:
ReferenceError: Unknown plugin "babel-array-includes" specified in "base" at 0
If I use the API (via gulp-babel) I get:
TypeError: undefined is not a function
at exports.default (/Users/me/deploy-tool/node_modules/babel-plugin-array-includes/lib/index.js:11:10)
which is a complaint about Plugin being undefined in the plugin :
/*
... babel-plugin-array-includes/lib/index.js: lines 11-13
*/
return new Plugin("array-includes", {
metadata: {
group: "builtin-post"
},
Any advice or opinion would be appreciated, thanks
EDIT #2: Partial solution: It seems it is not possible without using the Babel CLI at this time, which I will do with npm build scripts.
I'll leave this question open, pending my github issue.