Add support for ES6 module syntax

[simonexmachina]

Maybe I'm missing something, but I can't see how to use ES6 modules from CoffeeScript. We should have this.

[jashkenas]

It looks like there isn't yet a single JS runtime that supports ES6 modules yet: http://kangax.github.io/es5-compat-table/es6/

We should not have this until it's ready.

[simonexmachina]

Its preventing me from using an es6 module transpiler. Is there any way I can
prevent this from being a syntax error?

[davidchambers]

Is there any way I can prevent this from being a syntax error?

Could you include the code as JavaScript between backticks?

`import { Point, pow, sqrt } from 'math'`

# actual CoffeeScript code...

`export Segment`

[simonexmachina]

Yes, but it's pretty ugly! Thanks for the tip though, that works.

[alexgorbatchev]

👍

[mbixby]

+1

`export` Controller.extend # not working
   content: ...

vs.

# in 'controllers/configuration/items'
ConfigurationItemsController = Controller.extend
  content: ...
`export ConfigurationItemsController`

[abhayathapa]

+1. Great

[kimroen]

Is this something we should reconsider? With things like Ember App Kit and similar projects evolving, I think there's at least grounds to brainstorm a potential solution.

[mbixby]

Is the solution I posted (inline javascript) too invasive to be implemented?

[kimroen]

It's absolutely more of a nuisance than an actual issue.

Things like this: (export default)

export default Ember.TextField.extend({
  didInsertElement: function() {
    this.$().focus();
    this.$().addClass('focus'); // headless testing is brittle
  }
});

I would like to be able to write

export default Ember.TextField.extend
  didInsertElement: ->
    @$()
      .focus()
      .addClass 'focus'

[mbixby]

@kimroen see @jashkenas's answer above

[kimroen]

I obviously read through the issue before commenting :)

No worries, I just thought it was worth reconsidering. Do with as you please.

[alexgorbatchev]

👍

[mikejholly]

👍

[mrinterweb]

👍 I would really like this feature. I'd wager that we are going to start seeing more projects that use ES6 modules.

Even if the word "export" and "import" could be shortened to "exp" and "imp" respectively to get around keyword conflicts, that would be pretty great. I suppose an alias to those methods in the Square's ES6 module transpiler could be created. That may relieve coffeescript developers for a little time, but knowing that export and import are reserved words in ES6 makes me doubt that making those aliases outside of coffeescript would be well received.

[simonexmachina]

I've gotta say that, as much as I love CoffeeScript, I've moved away from
it in my latest project because it doesn't support import, export and
generator functions. It's a sad day, but all things must pass :)

[mrinterweb]

aexmachina, I'll much rather struggle to find a way to make CoffeeScript work with export and import than to stop using CoffeeScript. I keep hearing people say "JavaScript is fun." If JavaScript is so fun to write, why are there 100+ JS compilers?

I just posted an issue on the CoffeeScriptRedux project: michaelficarra/CoffeeScriptRedux#281
Alternatively, I suppose there is nothing that would stop anyone from forking CoffeeScript and changing the reserved words. Doing so would likely break backwards compatibility.

[vendethiel]

There are 100+ compilers because 1) it's the only language that runs client-side (expected chromium-dart and such) 2) it's an easy compilation target

[vendethiel]

I meant excepted*. I can't type on phones ;)

[xixixao]

Creating a version of CoffeeScript that targets ES6/traceur might become important in near future. We don't want lose @aexmachina! I wouldn't worry about the things that don't add to CS (like destructuring), but this seems to make sense (as do generators).

Most importantly, this doesn't break IE6 - adding this to CS doesn't force you to use it.

[michaelficarra]

@xixixao: Before we do that, we need to syntactically and semantically align existing overlapping features. Ellipses for spread/rest need to be prefix to match ES6. super semantics need to be changed to match ES6. But we need to wait until it's finalised before making any of those changes. I know I've gone into some detail on this in an issue before, but good luck finding it...

[xixixao]

@michaelficarra I do not agree with that at all. But I guess that my position breaks the good old just JavaScript motto. On the other hand, == is an overlapping feature and has different semantics, so maybe that motto is not meant to be interpreted in this way.

[tiye]

As I read an article, linking some words here.
http://shift.mirego.com/post/76526223016/javascript-next

I don’t think the team was enthusiastic about the idea of losing the classes, destructuring, rest arguments, defaut parameters and other cool features of CoffeeScript. I don’t blame them. I like these features too. But being future-friendly was more important to me. I wanted to use that ES6 syntax as soon as possible. With the new generation of auto-updating browsers, the time when we can all use ES6 is not so far away and being ahead of the curve could serve us well.

[DougPuchalski]

Backticks don't work with Ember App Kit Rails, at least.

[vendethiel]

Why not ?

[DougPuchalski]

@Nami-Doc A comparison here https://github.com/dockyard/ember-appkit-rails/issues/55#issuecomment-38101301

[vendethiel]

Unrelated, you're just using a global variable in the second example. Continue that discussion there though ;-).

[chrisnicola]

Worth noting that AngularJS 2.0 will be utilizing this feature. Might be time to revisit this soon.

[GeoffreyBooth]

@gajuro thanks for your input. I’m not an expert on React with CoffeeScript, but take a look at this example. I’ve also submitted a pull request to Meteor’s coffeescript package that passes backticked code through the ecmascript package, so that you can write ES2015 in backticks in CoffeeScript in Meteor. That should alleviate your boss’ concerns about future compatibilities, since you can have backticked code blocks (say, if you want to copy-paste from an ES2015 example). If you don’t want to wait for Meteor to accept the PR—and I can’t imagine it’s a high priority for them—you can save /packages/coffeescript from the PR branch into your project’s /packages folder. Keep in mind too that there’s no need for your project to use only one or the other: you can have .coffee and .jsx files both in your project, for example.

To the philosophical point, I really don’t know what’s holding back at least a statement on coffeescript.org outlining the intentions of the project. Any project contributor on this thread who can comment on that?

[jeremyhaile]

This is one of the arguments for us to move off of CoffeeScript. One of the advantages of CoffeeScript is its elegant syntax. Having to wrap things in backticks goes against that philosophy.

[danielbayley]

Having to wrap things in backticks goes against that philosophy.

Yet in ES6 backticks are a feature… 😷

[jeffmicklos]

whoa whoa, we need to chill out a bit here... @jashkenas reopened and acknowledge adding ES6 module support to CoffeeScript a couple months ago. I don't know if we need to keep complaining about this sort of stuff, all we can do is wait patiently with excitement and appreciation. Hold tight folks, the future is upon us!

[GeoffreyBooth]

Maintainers, is there anyone actually working on this? @michaelficarra, @jashkenas? Is there a plan for how this will be implemented? (I suggested a few potential designs above.) I would be happy to help contribute if there was some direction: a general plan for the design, a branch to contribute to, etc.

Ditto with a statement explaining CoffeeScript’s intentions regarding ES2015. I opened #4265 to track that separately, as that should maybe be hashed out first (unless it’s too big an issue to tackle).

[headbandno2]

Hey,

So from all import statement cases, hardest to implement is import "module-name";, b/c we have to lookup in that module file for what variables it's exporting. It might be that module isn't written in coffeescript at all. Other cases are simpler to parse since all new variables names are in code.

All possible import statement cases as per docs:

import defaultMember from "module-name";
import * as name from "module-name";
import { member } from "module-name";
import { member as alias } from "module-name";
import { member1 , member2 } from "module-name";
import { member1 , member2 as alias2 , [...] } from "module-name";
import defaultMember, { member [ , [...] ] } from "module-name";
import defaultMember, * as name from "module-name";
import "module-name";

Do you think it makes sense to partially implement import/export statements?

[carlmathisen]

Does it matter what it might import? The statements should just be allowed syntax, and then it's up to babel, node or compatible browsers to do the heavy lifting.

[backspaces]

Agreed!

I think the best approach is to wait until at least chrome and ffox have
the module script type:

<script type="module"> .. code w/ import </script>

It's "any day now"

I definitely do not recommend actually implementing it .. i.e. using
system.js or similar stunt. The implementation is a whatwg standard, so we
really gotta wait.

-- Owen

On Fri, May 13, 2016 at 9:06 AM, Carl Mathisen notifications@github.com
wrote:

Does it matter what it might import? The statements should just be allowed
syntax, and then it's up to babel, node or compatible browsers to do the
heavy lifting.

[GeoffreyBooth]

This is what I mean when I ask for direction. In my mind, “implementing” this feature is getting the CoffeeScript compiler to take input that’s something like this:

import { member } from "module-name"

and generate this output:

import { member } from "module-name";

And that’s it. I don’t want modules “implemented” the way Babel handles them, converting to require statements or anything like that. I’d rather that effort be left for some downstream tool, or a runtime that knows how to parse ES2015 modules natively. The destructuring could also be passed through as-is, since any downstream transpiler or runtime that can handle modules should also be able to handle destructuring.

The ES2015 import/export syntax is so Coffee-like already that the CoffeeScript module syntax could simply match it. Then the task is basically identifying such lines and treating them as more or less like backticked ES2015: just pass them through. If we want to make an alternate module syntax that’s even more Coffee-like, this comment above lays out pretty well what would be required. Maybe there are other steps we need to take to understand what symbols are imported, so that CoffeeScript doesn’t create empty var statements for them; I invite feedback.

Currently import and export are reserved words in CoffeeScript, so we could do a “pass-through” implementation without adding any compilation flags or anything else: the next version of CoffeeScript would simply allow import/export keywords, and when it finds them it passes those lines through unmolested. All old CoffeeScript code would still work, and compile the same way. This doesn’t solve the problem of what to do with the rest of ES2015 (for example, somehow telling the Coffee compiler to transpile => as =>) but we could at least handle modules now and postpone the day of reckoning of how to handle ES2015 more generally.

But again, this is just my suggestion. I don’t want to start working on this if this isn’t the implementation that the community desires. How can we get a decision made on how to move forward on this?

[backspaces]

This may be of interest: https://github.com/lautis/rollup-plugin-coffee-script .. which would avoid backticks for import/export, and produce import/export-less source .. making the problem go away completely! And the Rollup community is fabulous.

…

-- Owen

[xixixao]

@GeoffreyBooth If you read through this thread you should get a pretty clear idea of what the maintainers are happy with. You should give it a minute though, as there are many cases that aren't just a simple "pass through". You are correct that we should not compile down to anything else than ES6.

[lolmaus]

[rattrayalex]

While I disagree with the stance of the maintainers on this issue – and have left coffeescript with no plans to return, largely because of their attitude on the topic – they have certainly been clear about how they want to proceed and why.

Perhaps this issue should be locked from further discussion. At this point I don't think we're going to get anything more productive than @lolmaus 's comment[1] until a PR is submitted.

[1] for posterity, should it be deleted, a GIF reading "Zed's dead baby. Zed's dead".

[GeoffreyBooth]

@rattrayalex and @xixixao, how exactly have the maintainers “been clear about how they want to proceed”? Obviously @lolmaus seems to think the maintainers’ “clarity” is that they don’t care to solve this problem—which may be true in the sense that we haven’t seen much progress, but it’s pretty clear that both the maintainers and the community want to see CoffeeScript support modules: see @jashkenas asking for a proposal to support modules in Feb 2015, @jashkenas reopening the issue in Jan 2016, and plenty of discussion since then.

I’m not opposed to moving the discussion somewhere else if a maintainer has a suggestion. Perhaps this thread? I just want to try to reach some consensus on how to solve the modules problem, and collaborate so that we avoid duplicating effort.

[rattrayalex]

From @jashkenas earlier on this thread:

I'll reiterate that I personally think that the syntax should change slightly to allow valid ES6 module statements to pass through untouched without the use of backticks, but that nothing more should be done with them. This would make everyone happy, while being fully backwards-compatible - since export, import, and default are all presently on the reserved words list.

Sounds like a fine plan.

That said, they haven't acted (as far as I've been able to tell) or rallied anyone to act. My interpretation is their attitude is, "this should happen, in the most basic/minimal way possible, sometime later". It also definitely seems like a community-sourced PR would be welcome. The team is probably pretty overworked/burnt-out; there's over 300 open issues and over 30 open PR's on this project.

I'm just not sure anything productive can come out of this thread at this point, other than a PR. But, I'm new around here, so maybe this is how stuff gets done for this repo.

[tjad]

As a few others have realised and mentioned above, I will reiterate:

Coffeescript is in a bit of a pickle, and will have to start supporting(targeting) ES6/7 sooner or later (sooner rather than later). As the standards are set, and more browsers begin to support the standard, inevitably the js development community is going to be writing ES6/7.. This means that all new frameworks or newer versions of frameworks will incorporate ES6/7 and hence it will be difficult to use Coffeescript with those frameworks.

Presently, this is catastrophic, and it only gets worse, as right now everything is still transpiling to ES5 as browsers are not fully stable/supporting ES6+. So there is currently still a mutual point where coffeescript can meet new frameworks. As time progresses, ES6 will be the standard of choice for browsers, meaning that coffeescript will be left for legacy and new frameworks will not be transpiling back to ES5 meaning that coffeescript will not be able to use the new frameworks.

I urge the coffeescript team to think about this carefully.

[carlsmith]

Quickly looking through es6-features.org, it's mostly new helper functions, new types or just sugar that doesn't really matter to CoffeeScript. You could access most of the new stuff from CoffeeScript now, or just ignore it if it's only sugar. You can't use ES6 modules or classes in CoffeeScript though. Modules can be added, but classes will conflict with CoffeeScript classes, so it may never work.

It would be helpful to have a list of the new features that you need for new APIs, that you can't access through the JS that CoffeeScript compiles to now.

[lydell]

CoffeeScript 1.11.0 has now been released with import/export support. Thanks to @GeoffreyBooth for doing the hard work, and to @JimPanic and @rattrayalex for helping out.

[smith-chris]

Is there get and set syntax for classes in this new version of coffeescript? I need that to work with AureliaJS + Coffeescript

[carlmathisen]

@smith-chris See here and here for the work currently being done on classes.

[GeoffreyBooth]

@smith-chris Also getters and setters has its own discussion issue. Do you mind please adding a comment there explaining why get/set support is required to work with AureliaJS? We’re prioritizing interoperability concerns in driving current CoffeeScript development, so if there’s a case to be made why it’s required to use CoffeeScript with Aurelia, that will increase the urgency to address the lack of this feature.

[lolmaus]