Allow default export for any declaration #160
Conversation
|
Hey @dcreager @maxbrunsfeld, could someone merge this please? We're eager to try this out and we can't do so easily because it makes us set up experimental forks for both tree-sitter-javascript and tree-sitter-typescript. |
| @@ -79,6 +80,9 @@ module.exports = grammar({ | |||
| [$.assignment_expression, $.object_assignment_pattern], | |||
| [$.labeled_statement, $._property_name], | |||
| [$.computed_property_name, $.array], | |||
| [$.export_clause, $.object, $.object_pattern], | |||
| [$._import_export_specifier, $.object, $.object_pattern], | |||
| [$.export_statement, $._property_name], | |||
There was a problem hiding this comment.
Could you report what error you get if you remove these conflicts? I'm assuming that, by allowing export <expression>, we're creating ambiguities between "export clauses (e.g. export {foo as bar, baz}) and exported object literals (e.g. export {foo: bar}).
I'm wondering if the latter case is really allowed, or if we should keep default as required when exporting an expression.
There was a problem hiding this comment.
-
"Shorthand pattern" is valid JavaScript. I don't know which version added this syntax but it's also listed in the MDN page.
The way I comprehend it, this syntax is for exporting identifiers, not objects. It's sugar for export const c = c so you don't have to repeat the c twice. Fairly common to see in the wild.
From what I've tested in the links above, the "object version" of export { foo: bar } is not valid.
The error I get by removing the conflicts is:
Unresolved conflict for symbol sequence:
'export' '{' ',' • '}' …
Possible interpretations:
1: 'export' '{' (object_pattern_repeat1 ',') • '}' …
2: 'export' '{' (object_repeat1 ',') • '}' …
3: 'export' (export_clause '{' ',' • '}')
There was a problem hiding this comment.
I pushed the suggested fix, consisting in allowing expressions only after export default, not directly after export.
I made a new PR for this: #168
Allow default export for any declaration (extension of #160)
|
Closing this PR since it was extended by #168 which is now merged. |
This change would cover the syntax described in tree-sitter/tree-sitter-typescript#125 (comment) without extra grammar additions on tree-sitter-typescript.