Skip to content
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

ES2015 & 2016 Features meta-issue #560

Closed
29 of 64 tasks
samwgoldman opened this issue Jun 24, 2015 · 56 comments
Closed
29 of 64 tasks

ES2015 & 2016 Features meta-issue #560

samwgoldman opened this issue Jun 24, 2015 · 56 comments
Labels

Comments

@samwgoldman
Copy link
Member

samwgoldman commented Jun 24, 2015

Feel free to open an issue for any unchecked feature that doesn't already have one, but please try to keep discussion in a single issue if possible. Use cases (and test cases) are very welcome!

To report a bug with a completed feature, please open a new issue for the bug.

ES2015+

Proposals

Stage 4

Stage 3

Stage 2

Stage 1

Stage 0

@mroch
Copy link
Contributor

mroch commented Jun 25, 2015

this is super useful!

there are probably a bunch of new APIs that we need to add, too. for example, I just noticed that we don't have String.prototype.codePointAt (part of new unicode stuff)

@nmn
Copy link
Contributor

nmn commented Jun 29, 2015

Perhaps, add an ES7 section and mark async-await as done.

(BTW, I find it surprising that async-await is done before generators!)

@Globegitter
Copy link

Globegitter commented Jul 18, 2015

It seems there is an issue with ES6 Class support. I am using atom/nuclide IDE and having the following code:

export default class Resource {
  constructor(req:string) {
    this.req = req * 2;
  }
}

assignment of property req Property req not found in Resource even though I am defining it here in the constructor.

@gabelevi
Copy link
Contributor

gabelevi commented Jul 19, 2015

@Globegitter, Flow wants you to declare class properties like so:

export default class Resource {
  req: number;
  constructor(req: number) {
    this.req = req * 2;
  }
}

Why do we require this? Well, if we don't make people declare properties then we can't detect things like

function getReq(resource: Resource): number {
  return resource.rep;
}

We do realize this is a little bit more work for the developer, but we're hoping the benefits outweigh the pain.

@Globegitter
Copy link

Globegitter commented Jul 20, 2015

Aahh, I see, thanks @gabelevi For know I mostly want to use flow for its type inference with /* @flow weak */. The issue here is that I can not just put req; res; at the top, it does throw an 'Unexpected token;` issue.

Generally I do think this is an acceptable extra-effort, but why can flow not just get the information from the constructor itself? Is it that much more complex to see what this.req is assigned to and then look up the type in the constructor's parameter list?

As a side note kind of fitting to this, it would be great to see property initialiser support as mentioned here: http://babeljs.io/blog/2015/06/07/react-on-es6-plus/

@gabelevi
Copy link
Contributor

gabelevi commented Jul 20, 2015

I think at the moment that Flow requires type annotations for the class member properties you declare. So

req: any; res: any;

should work. I did recently change the parsing of that (7e5b2a9) in preparation for class property initializers. We absolutely are planning support for class property initializers. They solve so many problems! The one I hate the most is how you have to do

class Foo {
  constructor() {
    this.myCallBack = this.myCallBack.bind(this);
  }
  myCallBack() { ... }
}

but with class property initializers you can do

class Foo {
  myCallBack = () => { ... }
}

@Globegitter
Copy link

Globegitter commented Jul 20, 2015

Thanks for the quick response that all sounds good :) And yep it really does solve a lot of issues.

@samwgoldman
Copy link
Member Author

samwgoldman commented Jul 20, 2015

Generally I do think this is an acceptable extra-effort, but why can flow not just get the information from the constructor itself? Is it that much more complex to see what this.req is assigned to and then look up the type in the constructor's parameter list?

@Globegitter, good insight! Actually, flow used to do this, but the functionality was removed. I'm not sure about the details surrounding this, but there is some explanation in a comment in the source code.

Unfortunately, this change was from the days of "sync to upstream" so the diff is big and it's hard to see the implications in terms of the code changes themselves.

@oztune
Copy link

oztune commented Jul 28, 2015

image

^ What happened with let support?

I think it'd help if this was taken care of if only because at a glance it makes the whole project seem to be behind. For example it's being used as a con on this list, which happens to be a top result for googling "flow vs TypeScript"

image
http://www.reddit.com/r/javascript/comments/39cere/typescript_vs_flow_results_from_our_investigation/

Also in this comment:
image
http://www.reddit.com/r/javascript/comments/39cere/typescript_vs_flow_results_from_our_investigation/ct6xagb

Flow looks really promising, keep up the great work!

@samwgoldman
Copy link
Member Author

samwgoldman commented Jul 28, 2015

What happened with let support?

We're actively working on it. Please be patient.

@nmn
Copy link
Contributor

nmn commented Jul 28, 2015

@oztune by all means use my fork in the mean time: github.com/nmn/flow

  • Up to date with flow itself
  • Let/const support added by making flow treat them like var. (if you use Babel, the block scoping and const checking is already done for you)

@gregwebs
Copy link

gregwebs commented Aug 29, 2015

classes are checked, but class property initializers are not supported: can we have a check box for that? Making it hard for me to swallow ES6 classes right now.

An alternative approach to much of this work is to leverage babel more

@samwgoldman samwgoldman changed the title ES6 Features meta-issue ES2015 Features meta-issue Aug 29, 2015
@samwgoldman
Copy link
Member Author

samwgoldman commented Aug 29, 2015

@gregwebs class property initializers are not ES6/ES2015, but it's definitely on our radar. I think, instead of creating a separate meta issue for ES2016 features, we should just track that here. I'll make the necessary changes.

@samwgoldman samwgoldman changed the title ES2015 Features meta-issue ES2015 & 2016 Features meta-issue Aug 29, 2015
@gregwebs
Copy link

gregwebs commented Aug 30, 2015

Ah, in that case I will take any hack I can get. Seems to work to put this in the constructor:

      // fix broken es6 classes
      _.each(Object.getOwnPropertyNames( Object.getPrototypeOf(this) ), prop => {
        this[prop] = this[prop].bind(this)
      })

@Gozala
Copy link
Contributor

Gozala commented Sep 11, 2015

@samwgoldman I think it would make sense to update #431 to #784 given that's where the ongoing work is now.

@samwgoldman
Copy link
Member Author

samwgoldman commented Sep 11, 2015

@Gozala You're right! Thanks & done.

@cesarandreu
Copy link
Contributor

cesarandreu commented Sep 11, 2015

I'd vote for adding export extensions to the ES2016 list. (Not sure if they're supported?)

@samwgoldman
Copy link
Member Author

samwgoldman commented Sep 11, 2015

Is there an maintained list of the various proposals, along with the stage? Official would be ideal, but anything would help.

@cesarandreu
Copy link
Contributor

cesarandreu commented Sep 11, 2015

@samwgoldman there's a list of the ones that are available in babel.

@DimitryDushkin
Copy link

DimitryDushkin commented May 15, 2017

export default from './some-component';

throws "Unexpected string" error.

Issue is resolved via some "hack":

export { default } from './some-component';

@Jessidhia
Copy link

Jessidhia commented May 15, 2017

That is not some hack, that is the correct syntax (reexport the "default" export as an export named "default"). export default from is not valid syntax, but maybe the error message could be better.

@Pauan
Copy link

Pauan commented May 15, 2017

There is a proposal to add in this feature: [link]

And a related proposal: [link]

@DimitryDushkin
Copy link

DimitryDushkin commented May 15, 2017

Thank you. I thought it's already in specification, because webpack 2 understands export default from ....

@langri-sha
Copy link

langri-sha commented May 16, 2017

do expressions are now stage 0. Here's is the list of active ECMAScript proposals for the curious.

@lyleunderwood
Copy link
Contributor

lyleunderwood commented Nov 29, 2017

do expressions are now stage 1.

@leoselig
Copy link

leoselig commented Jan 3, 2018

@samwgoldman I believe this

is already done as of d3887c2.

Is this list still maintained?

@grundiss
Copy link

grundiss commented May 31, 2018

Still no support for do-expressions? :C

@PinkaminaDianePie
Copy link

PinkaminaDianePie commented Jun 2, 2018

Any news about do-expressions? They are extremely useful for FP-style, but I can't use flow together with them.

@verekia
Copy link

verekia commented Jul 17, 2018

Throw expressions: #6605

@bradennapier
Copy link

bradennapier commented Jul 20, 2018

do expressions ftw!

@bradennapier
Copy link

bradennapier commented Nov 27, 2018

Came here to say "do expressions ftw!" but I see I already did this in July :-\ heh

@Xunnamius
Copy link

Xunnamius commented Dec 31, 2018

Not seeing flow errors for throw expressions would be incredibly nice!

@SPAHI4
Copy link

SPAHI4 commented May 29, 2019

still waiting for do expressions

@goodmind
Copy link
Contributor

goodmind commented May 29, 2019

@SPAHI4 it is not standard

@goodmind
Copy link
Contributor

goodmind commented Jul 27, 2019

Updated list in post to reflect latest proposals

@fredericgermain
Copy link

fredericgermain commented Oct 13, 2019

I'd be very nice to have a status on import.meta (#6913)
@wchargin made a pull request a year ago and again two weeks ago, but @mroch in charge of it never commented. #6958

@gkz
Copy link
Member

gkz commented Sep 2, 2021

This issue is old and no longer up to date. We can track the remaining features left in individual issues.

@gkz gkz closed this as completed Sep 2, 2021
@noahehall
Copy link

noahehall commented Feb 4, 2022

@gkz the top-level await issue is closed :(

blah nvm found it ;)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests