Develop Reference

Why do some projects that use typescript/webpack also use babel to finish compilation

I've noticed some web projects using typescript and webpack also use babel to finish off the compilation. For example, they use ts to compile to ES2015 and then use babel to compile to es5. Why not just use ts directly to compile to es5?
Is it in the case the project also has js that needs to be compiled so they just use babel for everything? Or what am I missing?
Thanks.

There's a few possible reasons for this.
They're using Babel to automatically polyfill - TypeScript only performs syntactic transformations, leaving the user to figure out what runtime libraries they'll need to be around (e.g. Promise, Symbol, etc). This allows you to decide which implementation of these polyfills will work the best for you, but it can be a pain. Babel spares you the burden of thinking about that. It's a tradeoff.
They need it for a custom transformation - TypeScript has a transform pipeline, but it's only accessible when you use the TypeScript API at this point in time. If you're already using Babel and want to start using TypeScript, but you're already using a transform, this is a reasonable compromise.
It was created when TypeScript didn't support compiling generators to ES5 (or even back when TypeScript didn't support async/await in ES5) - TypeScript has supported async/await in ES5 since 2.1, and has supported generators behind the downlevelIteration flag since 2.3. Before that, users often relied on Babel to pick up the slack, but Babel isn't needed here anymore.
It was created before Webpack 2 and the project used a specific way of importing modules - TypeScript has an allowSyntheticDefaultImport option which tells TypeScript that default imports can be used to import certain modules. Babel supports this behavior, but Webpack didn't until Webpack 2 came out. Babel isn't needed here anymore for newer versions of Webpack.
This might not be the complete set of reasons, but it's a few I can think of off the top of my head.

Why not just use ts directly to compile to es5?
That is what I do.
About mixing Babel and TypeScript
There is no flaw in using the both together. Since both do:
(non js OR js) => standard js
You can do
(non js OR js) => standard js => es5
Either by TS -> JS -babel> ES5 or Babel -> JS -ts> ES5
The reason people do it is for varied syntax support : https://kangax.github.io/compat-table/
Personally
As mentioned. I don't use Babel as I TypeSafety is big for me and don't need to use syntax that isn't yet type safe 🌹

Typescript is the evolution frOM ES2016 onwards. Typescript helps the developer from c# and java background to become javascript developers using various tools. Visual Studio code, WebStorm, Sublime etc.
Why: We can not use Typescript alone for converting ts to ES5
Compiling to ES5 with TypeScript is not as complete as it is with Babel. Some modern language features, such as Array.prototype.find, cannot be compiled to ES5 with TypeScript.
Here is the link that will help you out: https://www.stackchief.com/blog/TypeScript%20or%20Babel%3F

Library versioning: Typescript / ES5

I want to write a small runtime environment independent library for managing general trees and I have a doubt on how to package / distribute the library after it's finished.
I have the following in mind:
Written in Typescript
Create Typescript definition template (d.ts)
Transpile to ES6 / ES5 and distribute as a node module
Possibility to use as a node module on the server, but also in the browser (commonjs / AMD compliant, but also just working without module loader / build step);
I've looked into the dist folder of ImmutableJS on Github to see how they do it, and got a bit confused:
It is written in ES2015
There is a TS definition template defined
But the ES5 version (immutable.js) does not seem generated (it looks like hand-written code). https://github.com/facebook/immutable-js/blob/master/dist/immutable.js
Hence, I wondered if they wrote the library in both ES2015 / ES5 (in parallel) and what influence this has on maintenance / syncing versioning.
It appears as if the ES5 version was written specifically for the browser (non-TS). Can you give me some pointers on what's happening here?

Babel and Browserify / Webpack confusion

Quick question. I am a bit confused about ES2015(ES6).
Let's say I use Babel to compile to ES6 Javascript to compliant ES5 for current browsers.
The import/export functions are already available in ES6 by using Babel. So why would I need something like Browserify or Webpack if I were to simply use these just to bundle my modules, when ES6 could do it for me?
Everywhere I go I see people using Babel in combination with Browserify or Webpack. Although I know something like Webpack can be used for more, but I wonder if it is also possible to bundle files using the ES6 syntax.
I might be totally in the wrong here and I might have gotten lost in the Javascript Jungle of 2016, so I hope someone can clarifty this for me.
Edit
Am I right to assume that the native ES6 import / export functionality simply does not bundle files? From what I have read so far I think you still need to include all the separate Javascript files but you simply import modules into each-others namespace by using the native import functionality?

Yes, using babel to transpile your ES6 imports into ES5 will work.
However, one advantage of using webpack is that creates one static file to be served up in your production environment.

Pre-ES6 has no native module system, so there are multiple systems constructed in userland code (e.g. CommonJS / Node modules and AMD). Those are what Babel converts ES6 module syntax to (and yes, you're correct that ES6 module syntax has no native bundling story anyway). Browsers have no knowledge of those userland APIs. Node implements its module system by wrapping a "module" in a function that injects require() etc. In a browser require() would just be a reference error. Browserify (or another bundler) makes it work in the browser, and bundles a whole dependency graph into a single script. So if the code is for the browser you're likely going to want to bundle it. If it's for Node you may not need to.
The import/export functions
Not functions, declarations.
if I were to simply use these just to bundle my modules, when ES6 could do it for me?
I wonder if it is also possible to bundle files using the ES6 syntax.
Am I right to assume that the native ES6 import / export functionality simply does not bundle files?
Yes. There's no native way to bundle ES6 modules. You can transpile ES6 module syntax to something like Node modules and bundle those.
From what I have read so far I think you still need to include all the separate Javascript files but you simply import modules into each-others namespace by using the native import functionality?
It's important to realize that while the syntax is standardized, a lot of the behavior isn't. There's a Loader spec under development to specify how modules will actually be located and loaded.
See also https://stackoverflow.com/a/33044085/1034448.

some es6 features are not understood by grunt uglify js?

I used grunt-uglify in my project and I'm working with es6. for some es6 features, such as fat arrow function, it's throwing an error. I think the uglify don't understant that syntax. so do i have a way to fix this issue. I mean can i use anything to make uglify understand all the es6 syntaxes?

You can use the harmony branch of grunt-contrib-uglify.
npm install git://github.com/gruntjs/grunt-contrib-uglify.git#harmony --save-dev
works perfectly with es6. No additional settings for grunt are required.

Officially there's no tool that minifies ES6 yet (Other tools like Google Closure compiler supports ES6 but it transpile it into "traditional js" and then it's minified).
Although not all the es6 features are supported in UglifyJs, the Harmony branch of UglifyJS2 seems to support arrow functions and other features.
You can read the discussion about it in the issue of github here. It seems there's not another option to wait (or create your own ES6 minifier).
Update
Now you have 2 options to minify ES6:
Babili, an ES6+ aware minifier based on the Babel toolchain (beta)
The Harmony branch of UglifyJS

A Grunt plugin ES6 parser, mangler/compressor and beautifier toolkit for ES6+ is now available:
https://github.com/adascal/grunt-terser
Great job, it just works as expected.
The harmony branch of grunt-contrib-uglify is deprecated, it's not a sustainable solution.

If the resulting code does not need to use ES6 syntax, it is also possible to transpile ES6 to ES5, before uglifying your code. This can for example be done with the Grunt task grunt-es6-transpiler.

I just updated to uglify-js#2.8.29 and it worked.

Browserify with typescript modules - what are best design practices?

I've got a browserify javascript project, where I include modules with the require statement. I'm now adding in some typescript, and it's working fine when I simply require the compiled javascript.
But typescript also has its own module statement. How does this relate to browserify/node's modules? Should I be using both? That seems redundant. Which type of modules should be used, and under what circumstances?
Thanks.

In newer versions of TypeScript (1.5) the module is deprecated in favour of namespace keyword. The keyword is to be used to create internal modules - allows you to organise your code internally.
So now it is more obvious that those are different things. Still TypeScript provides ability to create browserify/node's modules - external modules. For that you can use ES6 module syntax or older TypeScript's syntax. Then use browserify plugin (such as tsify) for more convenient builds.
More documentation about TypeScript modules and namespaces can be found here (also describing the older external modules syntax)
Which type of modules should be used depends on the project and taste of developers. If you target Node.js it worth to use CommonJS modules (IMHO ES6 syntax in TS and transpile it to CommonJS). If you are using browserify it is reasonable to use external modules, too. Namespaces is recommended to use only inside one file - hence internal modules.