Rescript-compiler: Generate es6 output

Created on 26 Aug 2016  路  6Comments  路  Source: rescript-lang/rescript-compiler

BS doesn't have to intentionally break compatibility with old browsers, so the current output is fine.

However there are some nice things about es6. Auto-bound, arrow functions are nice. let is nice (purely visual, since BS' var respects scope and everything). es6 classes could be either useless or extremely useful, object spread (not es6 per se) {...foo, bar: 1}, destructuring, etc.

Many of these have perf costs. Some of them probably none (e.g. destructuring).

HIGH enhancement

Most helpful comment

It's pretty easy to support es6 module, the major concern is that es6 module is _not native under NodeJS_, I am worried that people would start publishing es6 modules by default, then other users are forced to use a transpiler to consume js libraries..

All 6 comments

Also, generating import/exports from es6/7 modules would allow us to use Rollup for free. There are reasons why it's not that used over web pack yet but since we're transpiling this is a no-brainer. cc @Rich-Harris

@chenglou I've been working on comprehensive OCaml bindings to babel which might eventually make some of this easier since it would be possible to just re-use the babel AST and emitter. At the moment it uses gen_js_api pretty heavily so it's probably not suitable for integrating into BS directly. But it might be possible to go back and do it mostly with BS now using the GADT support. I haven't published the bindings yet but I will try to do it sometime soon.

In the meantime, I've been using a workflow where I postprocess the BS output with lebab (which can transform to es module style) and then do a bit more processing with some custom babel plugins to fix up exports, etc. Last time I tried, it worked pretty well (wrt to DCE) with rollup and webpack.

It's pretty easy to support es6 module, the major concern is that es6 module is _not native under NodeJS_, I am worried that people would start publishing es6 modules by default, then other users are forced to use a transpiler to consume js libraries..

From a personal point of view: if it's doable, do it (obligatory Shia LaBeouf here). The main reason being: all the other kids are doing it :)

Here's how TypeScript approaches the problem: http://www.typescriptlang.org/docs/handbook/compiler-options.html See --module and --target.

A lot of people develop their packages/modules in ES6 or languages that are compiled to ES6. With the advent of tree-shaking in Webpack and Rollup more and more people are doing it.

If you are developing _frontend_ code, this is usually not a problem. Everyone seems to be running babel these days.

If you are developing _library_ code, it's not really a non-issue, because a library developer should follow the same approaches as for JS/TypeScript:

  • distribute your code in ES5
  • point your package.json to ES5 code
  • provide source code in whatever language of your choice

^ this needs to be elaborated more by people who do lib/package development. See, as an example, MobX's package.json. It's a library developed in TypeScript. Its distribution includes various targets (with the hopes that tools know how to discover them :) )

We already support es6 modules, so it is a non issue any more?

OMG. I completely missed that :)

Nope, this should not be an issue anymore

Was this page helpful?
0 / 5 - 0 ratings