I have written a node module using ES7 features. I've also created a build script which transpiles to ES5.
Is there a way to publish the module, so that a node 8/9 user uses the original code and older node versions use the transpiled code?
The reason why I want this, is because I expect a better performance on the none transpiled code.
As far as I understand, the perfomance differnce between the transpiled code and ES7 code is negligible.
So it suffices to just publish the transpiled code.
Related
I'm trying to upgrade an angularJS project and I'm stucked on one question, but let me summerize the project:
We use AngularJS, gulp and node 8.
we currently cannot use the ES6 features, like arrow functions, const/let and so on.
I achieved that by installing babels plugin. But babel transpiles the code, and the company staff doesn't want that, cause it can make it difficult to debug on production(I know we can use sourcemaps, it will be suggested).
We just want to write ES6 code and read(on the browser) the same code as we do now (but with es5)
I upgraded node to 10 and I thought that by upgrading node, the app would accept the new ES6 features. But still crashes when using es6 syntax.
Can someone tell me why? If the browsers accepts, why gulp doesnt?
When I first studied TypeScript, I found that node.js doesn't execute TypeScript, so you need to install a TypeScript compiler that converts your TypeScript code into JavaScript.
I searched until I found ts-node (TypeScript execution and REPL for node.js), but when I read the documentation I found that they do the same (here). Even deno (A modern runtime for JavaScript and TypeScript), is doing the same (here).
So my question is: are there any engines to execute TypeScript code without converting it to JavaScript?
No, TypeScript is not a "standalone" language in that sense. It is and always will be a superset of JavaScript. This is why the TypeScript Compiler is often referred to as a transpiler: it doesn't compile to a lower-level language. After tsc has run its checks it transforms existing source to JavaScript by simply stripping out all the TypeScript constructs.
From the intro of the official TypeScript Handbook:
The goal of TypeScript is to be a static typechecker for JavaScript programs - in other words, a tool that runs before your code runs (static) and ensures that the types of the program are correct (typechecked).
So in order to execute TypeScript, you will always need a JavaScript engine. You could adapt an existing JavaScript engine (or build your own) to understand TypeScript as well, but still it would always first have to be an engine conforming to the ECMAScript specification.
Deno is no different. It has a built-in TypeScript Compiler, which is a copy of the official one. From the TypeScript chapter of the Deno manual.
At a high level, Deno converts TypeScript (as well as TSX and JSX) into JavaScript. It does this via a combination of the TypeScript compiler, which we build into Deno, and a Rust library called swc. When the code has been type checked and transformed, it is stored in a cache, ready for the next run without the need to convert it from its source to JavaScript again.
After transpilation, Deno runs the output JavaScript on Google's V8 Engine, the same engine used in NodeJS and Chrome.
As of now there are no typescript aware V8-like runtime egnines.
It's unlikely we would see one. Sometime in the future TC39 will decide on official JS-With-Types proposal. And then typing and correspond
optimizations would be gradually added to V8 itself.
Though, it unlikely would be compatible with typescript directly, but easily transpilable back and forth.
At the moment there are several R&D AOT compilation (directly to static native binaries) projects for the typescript, or at least for the viable subset of it.
https://github.com/ASDAlexander77/TypeScriptCompiler
I was learning babel and webpack and then it turns out I need to install node.js to run them both and I asked myself WHY? Then according to my research, we need node.js for webpack and babel since both of them were written in JS and to run that JS code which transpiles( for babel) and bundles up the code(for webpack). Also, another reason is that since both babel and webpack handles our JS code outside of the browser, this is the reason to use Node.js. Are these reasons true?
According to the Node.js website -
Node.js® is a JavaScript runtime built on Chrome's V8 JavaScript engine.
Webpack and babel (along with many other tools you might use for frontend development) are written in javascript and since they are command line tools, they need a way to run outside of the browser (directly on your machine).
They could have used some other language to write the tools but since they chose to write them in javascript, Node.js is the only feasible options right now.
In case you are interested, the original creator of nodejs
Ryan Dahl has built another secure runtime environment for Javascript/Typescript called Deno
Yes, at the moment the node.js project is non-portable by full open source disclosure nor extension to port node.js commonjs without a just in time transpiler with a service worker on a server.
Definitions: FHC = "from half court"
Babel and webpack
(1) transpile/move (write&read, not ln -s sym...bolic link) & (2) compost/pile onto a JIT target,
like v8 or other browser-javascript-interpreters. v8 on a service worker can compile on the edge just in time for interpretation in a browser v8 environment but still on the cloudflare edge server.
Declare (FHC) Allegedly, rust provides webassembly modules with the lipid [llvm-]wrappings
that nucleic acid exocytosis needs to be a full-blown virus, err I mean
Initiation Routine needs to be a targetable JIT extension!
A compiler/transpiler still requires it's target-scope receivable. Declare (FHC) Emit is to execute as compile is to interpret, even AST.
I have several backend-only Node.js projects which use a simple TypeScript config.
Before March 2018, I had this in package.json:
"devDependencies": {
"#types/core-js": "^0.9.46",
"#types/node": "^9.6.2"
}
since ~March 2018, I have been omitting "#types/core-js" and everything seems to compile fine. Do we need "#types/core-js" anymore?
I have several Node-based projects written in TypeScript. I never ever used #types/core-js in my projects. So it is definitely not necessary to use #types/core-js in order to write Node-based code. Having #types/node, on the other hand, is a boon if you're going to use Node's API.
The first thing to do if you run into a compilation issue that appears to be caused by the compiler not knowing about features introduced in ES6 is to set lib to load the proper typings you need. For instance, if you decide to target es5 but want to use methods, classes, functions introduced in ES6, you do need to specify "es6" in your lib setting because by default the target es5 loads the lib es5 too. (According to the documentation, a target of es5 sets lib by default to DOM,ES5,ScriptHost, whereas a target of es6 sets lib by default to DOM,ES6,DOM.Iterable,ScriptHost.)
I've run into some very rare cases where there's something missing in the es6 lib. In such cases, I just write a definition to fix that specific problem. Loading #types/core-js might also fix the issue, but it also contains a lot of other things that are not necessary, and it adds a dependency to the project, which then must be managed, etc. Not worth it.
The focus above was Node projects, but even in web-based projects where I have a dependency on core-js I don't use #types/core-js. As I see it, the presence of core-js in a project should be entirely transparent to the project's application code. I'm writing code made to run on any platform providing an API that conforms to ES6 or later, I'm not writing code made to run with core-js specifically.
You should only need #types/core-js if you're using something that is in that declaration that is not available in your TypeScript declarations for your major version. This is useful if you're expecting to use core JavaScript ES6 features that are in core-js but were not implemented in the version of TS you were using at the time. There's more information available on the TS GitHub related to your question but in all reality if you're just using ES stuff that's there now, no you shouldn't need it anymore.
edit: Before I had stated it as node, but in all possibilities since it's TS it probably didn't know how to compile to the target without the declaration. As of TS 2 and NodeJS 6 you shouldn't really need it anymore.
Some Node.js projects use things like Babel, Gulp, Webpack. Other Node.js projects don't use such things. Do I have to use them in my Node.js projects and why? Perhaps you know different cases when I should take one of these decision?
No, you do not need.
Webpack is a bundler, it is intended to help packing up multiple files into one single file. Throughout this process you can transpile the code to apply modifications on it, eg: convert from es6 to es5 (if needed).
To transpile your code from es6 to es5, you are going to need babel, where you can do a lot of stuff with that.
Gulp is a task runner/manager, not used that often since most of people use webpack nowadays. But still useful for a bunch of stuff.
If you are going to develop pure node.js projects, you don't have to worry about this. For web you should be aware of all of these tools.
I've found Babel, Gulp, Webpack can be used in Node.js projects with cases:
you need to minimize production code.
you'd like to use all ES6+ features (like 'export' and 'import', decorators).
you want to use JavaScript extensions like TypeScript.
If for some reason your project contains .js files are intended to run in different environments (Node.js, casperjs, browsers), you would like to use ES6+ inside all .js files.