I was attempting to use Traceur for a few small client-side micro libraries that I maintain. I would like to refactor them to use "classes" and a few other ES6 features and then compile an es5 version for production.
However, once I add classes the compiled out requires the runtime which is really big for all I need (just extending constructor functions). Is there a way to configure it so that it puts just what it needs to run into one file like CoffeeScript?
You can build your own runtime by following the recipe in the Makefile and omitting the files you don't need. traceur is 'self-hosted' so you use the ./traceur command with inputs and flags to create an output file which is the runtime source. Start with make bin/traceur-runtime.js then whittle down the files until you have what you need.
We are working on an automated way to do this, but it's not likely to be done soon.
Related
I am running on a huge project with thousands of .js files that are written in es5, and for many reasons and benefits of TS, we've decided to start migrating to TS, after a couple of days and many pieces of research, I am going to elaborate a couple of points:
To start migrating from es5 to ts we can start either by two ways:
First way:
1- Installing ts, creating tsconfig with allowJS set to true then start changing the extension of files to .ts and everything will work by default
2- As we want to migrate gradually we don't want at once to replace the global scripts to native modules, in other words, we don't want immediately to type import and export, but instead we want to keep the old way global scripts and use /// <reference path=""> to load dependencies
3- after previous step we can gradually start turning the files into native modules esm
Second way:
1- As I've read about UMD it will work on both borwser(client) and server, which means support all type of modules AMD, CommonJS, SystemJS and Native ES modules
2- after re-writing the scripts in UMD fashion, we can gradually start moving our scripts to ESM
last but not least, and regarding the intelligence we'll start writing .d.ts files accordingly or we can rely on ts-loader to generate the files
lastly, we either go with ts-loader or babel but we are not sure if there are couple of limitations for each of which
Any idea is really appreciated on what is the best way to start migrating
Maybe this tool can help you:
https://github.com/airbnb/ts-migrate
ts-migrate is a tool for helping migrate code to TypeScript. It takes a JavaScript, or a partial TypeScript, project in and gives a compiling TypeScript project out.
ts-migrate is intended to accelerate the TypeScript migration process. The resulting code will pass the build, but a followup is required to improve type safety.
If possible, start fresh and write migration script which does copy/paste task of code. In which Project setup will be error free in term of compile/build/run/lint. So even in future there won't be any issue you just need to add modules. You can migrate module by module.
Now if you are migrating to TS means not just by extension or package type, because it won't benefit more, you will need to change in code like types, interfaces, configs etc.
So starting a fresh project and then converting code to TS and then gradually moving should be better.
I would suggest you should write new modules in typescript and slowly convert existing files and modules to typescript. But keep the output in js only. Convert each ts file into js, For e.g, if you have a module Utils create two folders inside this ts and js. Write a build script which will convert ts to js and move inside the js folder. This way you will be converting all files into ts. For import/export you can start it for the new module. I have done the same in one project.
Regards,
omi
I appreciate all the answers but for my case it is so complicated because ts modules will affect the scope, what I found useful is using what so-called shimmer modules in webpack which allows a feature called imports-loader which I can use to manipulate the scope of js, hence nothing is broken, then I can move file by file to start migrating
I am starting a new Web project and trying TypeScript, mainly as an ES6 transpiler but also with the additional benefits of type checking, especially for existing libraries such as jQuery combined with the DefinitelyTyped type definitions.
Since the latest version, TypeScript supports both its own internal modules and ES6 modules, which calls "external" modules. Because ES6 is more standard than TypeScript, my intention is to use ES6/external modules rather than the traditional/internal TypeScript modules.
I have my own code defined in several files/modules, but I want the build to generate a single .js file that I can load from the browser.
The problem is that as far as I can tell, TypeScript is only able to generate a single output file when using its own module format. If I try to use ES6 external modules, then it generates a separate .js file for each .ts file.
This means I would need to concatenate them using browserify, but also I want source map support, which means that I should configure browserify for input and output source maps, then combine it with exorcist so the source map is extracted out of the bundle.
That looks like a very complex build setup. Isn't there a more straightforward way, maybe directly supported by TypeScript? What is the best approach? What do you recommend?
Let TypeScript do what it does best...
Add types to JavaScript be it ES5/ES6/ES7
Transpile to ES5
Resolve modules via the specified module syntax (commonjs, amd, umd, system)
Then find another tool that will take the separate files and combine them into a single bundled file (in the right order). My suggestions are to look into:
webpack
browserify
tsify
Are you looking for a solution in the browser? If so, I highly recommend my project Zwitterion. It removes the complicated build steps, and let's you include TypeScript directly into the browser with normal script tags. You can also use standard ES modules directly, with no extra setup. It uses SystemJS under the hood to achieve that. There is no source map support yet, but that should come. If you would like more information besides what's in the README, you can read "Zwitterion, forget the build step".
I have a library that I'm building in TypeScript. I'd like to include this library in both TypeScript and JavaScript Node projects. What is the general strategy to do this? Should I compile and have two versions or is there some other strategy I should be using?
I'd like to include this library in both TypeScript and JavaScript Node projects. What is the general strategy to do this?
Compile with the following to get the js output:
--module commonjs --outDir ./dist
This should make your project consumable by JS projects. To make it consumable by TS projects you need to generate a declaration file. This can be done using https://github.com/SitePen/dts-generator See usage for details : https://github.com/SitePen/dts-generator#usage
Note: There is discussion on removing the dts-generator dependency : https://github.com/Microsoft/TypeScript/issues/2338
In most cases I have seen you have a /dist/ folder where the compiled JavaScript is located.
Usually there is also a minified version like yourfilename.min.js - the rest is either outside or in a /src/ folder, so outside you have only the license/readme.md, package.json left and maybe the file for Grunt/Gulp (it is considered polite to - if you use a taskrunner - include a Grunt/Gulp file for compiling the typescript and minify the .js file afterwards, as far as I got it)
If you want to preserve the TypeScript advantages when using it in TypeScript projects, then you obviously have to expose a TypeScript version of the code so the TypeScript compiler can see the TypeScript declarations for your interface.
But, if you want people to be able to use your library in plain Javascript projects (that don't compile TypeScript into JS), then you have to offer a version that has a plain Javascript interface and where the code has already been compiled into plain JS.
So, if you want both of those advantages, then you have to offer two separate versions. The plain JS version can obviously just be a compiled version of the TypeScript (compiled into plain JS).
Is there any software that I can use to compile nodejs program?
The reason I want to compile nodejs code is to make it safely distributable.
For example for a desktop application,etc.
And also I want to know whether nodejs will execute faster if compiled as it is asynchronous already?
Javascript is not a compiled language and Node.js is Javascript. It will be executed and interpreted at runtime. You can process your javascript with tool like grunt.js for example lint-test and uglify it, but be careful so that do not break the npm system since it is based on certain conventions.
To package your javascript for distribution in the node.js context build an npm module.
https://www.npmjs.org/doc/developers.html
For distributing javascript to the desktop client: Remember it's Javascript an it need to be executed in the Javascript VM. So to have some UI you need to run it in the browser or you need to have some webkit compiled dll to run your code...
something like this...
http://www.tidesdk.org/
You can also use: http://github.com/rogerwang/node-webkit (Thanks to #edi9999)
There is no way to do that with v8, it has only JIT option. It possible to make a "snapshot" with v8, but it's not exactly the same as compilation and node.js doesn't have support for this feature (also it might produce slower code). Also all your code will be available with toString() of functions.
You might be interested in JXcore project. It is a fork of node and as far as I know has some solution to code protection. Also one of the project goals is to develop javascript-to-LLVM compiler. Of course it can't have full support for ES specification (eval, new Function etc).
There's no way to 'compile' a nodejs program, as the javascript is interpreted at run time.
However, if you want to protect your code, you could maybe use something like Uglify JS to make the javascript less readable. However, this won't hinder people to change around your code.
The closest you might get to acheiving your goal is to create a self-executing Javascript bytecode wrapper.
A project that does this is pkg
It somehow creates a self-contained binary executable from Javascript, including module dependencies and asset files and produces a self-contained executable.
Installation and use is easy:
$ npm install -g pkg
$ pkg index.js -o my-program
$ ./my-program
It seems the resulting binary contains nodejs bytecode. It appears that you can cross-compile.
In Node.js, you can dynamically "require()" any javascript file likewise to PHP's require. I'd like to use this in my client-side code just for ease of development but not actually call a javascript function, but have a compiler replace the line with the contents of the respective file; effectively concatenating the files, not one after another, but inline within the code of one of the files. The closest thing I have found to this is smash. Are there any compilers, minifiers, etc that can do this?
Browserify might not be exactly what you want but it does definitely help with the ease of development issue. When you use Browserify, your code is your build tool. Browserify gives you all the benefits of writing code in node (no anon functions to avoid globals, npm, simple requires, imports instead of namespaced globals) and it allows you to package that code to run on the client with one command and only load one file.
You can checkout my open source js framework Luc JS for an example. It runs on node and IE6. I'm able keep the code modular and build the single browser file with a one line command.