-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for ES6 module syntax #3162
Comments
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. |
Its preventing me from using an es6 module transpiler. Is there any way I can |
Could you include the code as JavaScript between backticks? `import { Point, pow, sqrt } from 'math'`
# actual CoffeeScript code...
`export Segment` |
Yes, but it's pretty ugly! Thanks for the tip though, that works. |
👍 |
+1
vs.
|
+1. Great |
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. |
Is the solution I posted (inline javascript) too invasive to be implemented? |
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' |
@kimroen see @jashkenas's answer above |
I obviously read through the issue before commenting :) No worries, I just thought it was worth reconsidering. Do with as you please. |
👍 |
1 similar comment
👍 |
👍 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. |
I've gotta say that, as much as I love CoffeeScript, I've moved away from |
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 |
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 |
I meant excepted*. I can't type on phones ;) |
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. |
@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. |
@michaelficarra I do not agree with that at all. But I guess that my position breaks the good old |
As I read an article, linking some words here.
|
Backticks don't work with Ember App Kit Rails, at least. |
Why not ? |
Unrelated, you're just using a global variable in the second example. Continue that discussion there though ;-). |
Worth noting that AngularJS 2.0 will be utilizing this feature. Might be time to revisit this soon. |
@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 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? |
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. |
Yet in ES6 backticks are a feature… 😷 |
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! |
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). |
Hey, So from all import statement cases, hardest to implement is 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 |
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. |
Agreed! I think the best approach is to wait until at least chrome and ffox have It's "any day now" I definitely do not recommend actually implementing it .. i.e. using -- Owen On Fri, May 13, 2016 at 9:06 AM, Carl Mathisen [email protected]
|
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 The ES2015 Currently 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? |
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
|
@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. |
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". |
@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. |
From @jashkenas earlier on this thread:
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. |
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. |
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. |
CoffeeScript 1.11.0 has now been released with |
Is there get and set syntax for classes in this new version of coffeescript? I need that to work with AureliaJS + Coffeescript |
@smith-chris See here and here for the work currently being done on classes. |
@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. |
Maybe I'm missing something, but I can't see how to use ES6 modules from CoffeeScript. We should have this.
The text was updated successfully, but these errors were encountered: