Esprima parser update
addyosmani opened this issue · comments
As per the readme, the ES6 Esprima Harmony parser is being used to do parsing, loaded only when necessary. This parser still uses an older syntax, which is currently the major critical issue to sort out for this polyfill.
@guybedford suggested that we explore alternatives and I agree.
I liked the Esprima parser because it is relatively small (60KB minified), and also would allow for polyfilling other ES6 functionality like classes, let etc in the same way the module syntax is handled here. In this way, there is the potential for this module to become the gateway to other polyfill modules. I created the ES6Parser.addPolyfill function to allow for this, although there is still some working out to do here.
I believe @ariya is keen to support the ES6 functionality of Esprima, so perhaps we just need to reach out in getting the Harmony branch updated.
The alternative would be to use a smaller parser just for module syntax, which could be an equally good option for this polyfill. As I say, I'm open to the options here.
To keep tabs on the Esprima issue, the link is here - https://code.google.com/p/esprima/issues/detail?id=410
I think it's worth reaching out to @ariya about the branch. If we can't get it updated ourselves, perhaps a member of the community would be interested in helpful with the effort.
I'm also unsure if this would be helpful, but I just ran into this pseudoimplementation of the ES6 module loader proposal https://github.com/jorendorff/js-loaders. Could be useful for reference in other areas if not here.
Yes the loader there has an issue queue that shows the current spec changes under discussion. It is definitely useful to keep an eye on. My hope in updating the polyfill was that the spec is coming to some consensus now. I will be keeping changes up to date here as the spec updates though. I've also included a warning note in the readme about this. Let's hope they don't give us too much grief!
@guybedford I'm definitely interested in updating the implementation to follow the latest specification!
I'll see what I can do next week.
@ariya thanks for the quick response, that would be amazing if it works out.
That would be fantastic, @ariya! +1 on our thanks for looking into this.
@guybedford It'll take a few days for me to catch up with the module syntax updates. If you feel brave and want to summarize it (at https://code.google.com/p/esprima/issues/detail?id=410), that'll be great!
@guybedford Check out the latest harmony branch and see if this is complete (wrt module syntax). You can use http://esprima.googlecode.com/git-history/harmony/demo/parse.html to play with different syntax and see the syntax tree (notice some changes).
From the unit tests, the example code which is now recognized:
module "crypto" {}
module "crypto" { module "e" {} }
module crypto from "crypto";
module "a" { export default answer }
module "lib" { export var document }
module "lib" { export var document = { } }
module "lib" { export let document }
module "lib" { export let document = { } }
module "lib" { export const document = { } }
module "lib" { export function parse() { } }
module "lib" { export class Class {} }
module "lib" { export * }
module "security" { export * from "crypto" }
module "crypto" { export { encrypt } }
module "crypto" { export { encrypt, decrypt } }
module "crypto" { export { encrypt, decrypt as dec } }
import "jquery"
import $ from "jquery"
import { encrypt, decrypt } from "crypto"
import { encrypt as enc } from "crypto"
import { decrypt, encrypt as enc } from "crypto"If something is still missing, please post the notice to https://code.google.com/p/esprima/issues/detail?id=410 and I'll try to fix it as soon as I can.
@ariya Really nice work! I was wondering: are you basing your tests on code coverage of the latest draft spec?
Draft Rev 15 Section 14.2 on Modules is still empty. I use the harmony wiki on Modules as the reference.
@ariya perfect, thank you so much! I will get on this today.
On Sunday, July 14, 2013, Ariya Hidayat wrote:
@guybedford https://github.com/guybedford Check out the latest harmony
branch and see if this is complete (wrt module syntax). You can use
http://esprima.googlecode.com/git-history/harmony/demo/parse.html to play
with different syntax and see the syntax tree (notice some changes).From the unit tests, the example code which is now recognized:
module "crypto" {}module "crypto" { module "e" {} }module crypto from "crypto";module "a" { export default answer }module "lib" { export var document }module "lib" { export var document = { } }module "lib" { export let document }module "lib" { export let document = { } }module "lib" { export const document = { } }module "lib" { export function parse() { } }module "lib" { export class Class {} }module "lib" { export * }module "security" { export * from "crypto" }module "crypto" { export { encrypt } }module "crypto" { export { encrypt, decrypt } }module "crypto" { export { encrypt, decrypt as dec } }import "jquery"import $ from "jquery"import { encrypt, decrypt } from "crypto"import { encrypt as enc } from "crypto"import { decrypt, encrypt as enc } from "crypto"
If something is still missing, please post the notice to
https://code.google.com/p/esprima/issues/detail?id=410 and I'll try to
fix it as soon as I can.—
Reply to this email directly or view it on GitHubhttps://github.com//issues/10#issuecomment-20935632
.
Doesn't seem to support top level exports which I believe causes a file to be implicitly picked up as a module.
@matthewrobb is correct, top level exports are necessary for loading module scripts (http://jsbin.com/afehov/1/edit). Apart from that it all seems to be working great.
A reminder: if there's any concern with the syntax support, please post your comment to Esprima issue 410.
If in the future I need to refer/search to those syntax discussions again, I won't be able to remember that I also need to visit this one (or any other project's issue tracker, for that matter).
The syntax is now all there thanks to the esprima updates. @ariya thank you so much again!
We just need to clarify the export default syntax now. I am awaiting some further specification feedback, which should hopefully be coming soon.
I believe we have an up-to-date syntax now. Closing, although we can reopen if there are any further specification changes.