Skip to content

Babel 6 types#162

Merged
benjamn merged 1 commit intobenjamn:masterfrom
hzoo:jamestalmage-make-forkable
Nov 4, 2016
Merged

Babel 6 types#162
benjamn merged 1 commit intobenjamn:masterfrom
hzoo:jamestalmage-make-forkable

Conversation

@hzoo
Copy link
Copy Markdown
Contributor

@hzoo hzoo commented Jul 4, 2016

Fixes #132
For babel pr: babel/babel#3561
Also ref benjamn/recast#298

First 3 commits are from #145 (fixed merge conflicts by preferring the changes in the PR).

You can review that PR or this one with whitespace off for a better diff https://github.com/benjamn/ast-types/pull/162/files?w=1.

My commit adds the babel 6 types (not sure if it's right though, so please review!).

References:

cc @jamestalmage @benjamn

@@ -0,0 +1,117 @@
module.exports = function (fork) {
fork.use(require("./babel"));
fork.use(require("./flow"));
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do I need to fork both? or should babel fork flow instead of es7?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you should fork both. It's conceivable people will want to use the types defined in ./babel without those defined in ./flow, right? If ./babel forks ./flow, it should imply that those type definitions somehow depend on ./flow.

@hzoo
Copy link
Copy Markdown
Contributor Author

hzoo commented Jul 4, 2016

General question - is it better to just define a new type with everything from scratch (base, build, field)? Some of the changes are literally just a name change so that probably doesn't have to be.

@hzoo hzoo changed the title Jamestalmage make forkable Babel 6 types + forkable Jul 4, 2016
@hzoo
Copy link
Copy Markdown
Contributor Author

hzoo commented Jul 4, 2016

Should I be modifying main.js?

@jamestalmage
Copy link
Copy Markdown
Contributor

fixed merge conflicts by preferring the changes in the PR

That was so long ago, there are probably changes that should have been merged more carefully. I can take a look at #145 again tonight.

@jamestalmage jamestalmage mentioned this pull request Jul 6, 2016
@jamestalmage
Copy link
Copy Markdown
Contributor

jamestalmage commented Jul 6, 2016

General question - is it better to just define a new type with everything from scratch (base, build, field)? Some of the changes are literally just a name change so that probably doesn't have to be.

My gut says just redefine. Babel has moved far enough away from esprima compatibility, that attempting to share base types seems likely to create some amount of pain, and I don't really see much of an upside. We are to the point of needing a custom fork anyways, so might as well just make the entire tree conform to the Babel way of doing things.

That said, simple name changes can probably just be accomplished with:

def('newName').bases('oldName')

(you might need to redefine build in that case, not sure)

@hzoo
Copy link
Copy Markdown
Contributor Author

hzoo commented Jul 7, 2016

Rebased again

def/babel6.js Outdated
// Split Literal
def("StringLiteral")
.bases("Literal")
.bases("Node", "Expression")
Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Node is not important here, nor for the other Babel *Literal types, because Expression <: Node.

@benjamn
Copy link
Copy Markdown
Owner

benjamn commented Jul 11, 2016

  1. Can you rebase now that Make forkable #145 has been merged?
  2. I believe you can solve the test failures by creating multiple forks for different tests, instead of using the default fork that includes all the defs.

def/babel6.js Outdated
def("ObjectPattern")
.bases("Pattern")
.build("properties")
.field("properties", [or(def("RestProperty"), def("ObjectProperty"))])
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it should be Property, not ObjectProperty, per https://github.com/estree/estree/blob/f32646033ed12e6aaa7f5cd496d936a8f8de194e/es2015.md#objectpattern

There are a couple of places in ESTree where nodes have different type values like this, but I don't think ast-types has a way to represent this.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you mean here though? I'm defining all the different types from ESTree (including ObjectProperty above) - I thought we would be forking to support the different AST types in babel (6).

https://github.com/babel/babylon#output

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note how ObjectPattern.properties is an array of ObjectProperty's, like you have, but ObjectProperty's type field is "Property", not "ObjectProperty." def("ObjectProperty") requires an ast with { type: "ObjectProperty" }, but estree says it should be { type: "Property" }

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After v6, Babel isn't following ESTree completely so I had to make this PR to make it work with recast. Yeah it's totally correct it should be Property but Babylon won't produce a type of Property anymore so I'm using ObjectProperty if that makes sense (unless I'm misunderstanding something)

@suchipi
Copy link
Copy Markdown

suchipi commented Oct 4, 2016

I'd like to see this merged... how can I contribute? What needs to be done to fix the tests? I'm not familiar enough with the forking model in this codebase to understand how to fix failures.

@hzoo hzoo changed the title Babel 6 types + forkable Babel 6 types Nov 3, 2016
@hzoo
Copy link
Copy Markdown
Contributor Author

hzoo commented Nov 4, 2016

.build("argument")
.field("argument", def("Expression"));

def("ForAwaitStatement")
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

.bases("Type")
.build();

def("EmptyTypeAnnotation")
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

.field("value", def("Type"))
.field("optional", Boolean);
.field("optional", Boolean)
.field("variance",
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

.field("id", or(def("Identifier"), def("Literal")))
.field("body", def("BlockStatement"));

def("DeclareModuleExports")
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@hzoo
Copy link
Copy Markdown
Contributor Author

hzoo commented Nov 4, 2016

Finally got around to fixing these.. @suchipi (I didn't understand the forking either).

Tested with benjamn/recast#299 (would error that node isn't printable, etc)

@benjamn benjamn merged commit d173232 into benjamn:master Nov 4, 2016
@hzoo
Copy link
Copy Markdown
Contributor Author

hzoo commented Nov 4, 2016

Thanks @benjamn!!! much excite 😍

@hzoo hzoo mentioned this pull request Nov 4, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Support for new babel types

5 participants