-
Notifications
You must be signed in to change notification settings - Fork 29
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
@jdalton Looks like acorn@5.0.0 got a bit more strict about duplicate variable declarations and import specifiers.
- Loading branch information
Showing
2 changed files
with
18 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
19add56
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Aren't duplicate
let
/const
and import specifiers invalid JS?Does reify rely on that or some part of nested imports?
I'm unclear on how its affecting reify and its tests.
19add56
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's the
switch
issue you mentioned the other day:reify/test/export-tests.js
Lines 250 to 267 in 2254a6b
Just to reiterate, I really believe Reify should not implicitly enforce any form of unnecessary strictness.
19add56
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, I agree. Enforcing is what the runtime does. Does acorn do its validation as it's generating its ast? Are there other gotchas? Maybe the
acorn/dist/acorn_loose.js
andparse_dammit
is a safer way to go.For example I do dumb stuff all the time while deving. Would a syntax error on my part throw first in reify or the runtime (I'm hoping runtime).
19add56
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It happens in the middle of parsing, looks like: https://travis-ci.org/benjamn/reify/jobs/215909574
An unrecoverable syntax error would probably keep Reify from parsing the AST. Perhaps we should think about whether Reify should just swallow parse errors and leave the code untouched. There's a chance the code would still work in Node, and Node should probably be the one to throw the error that the developer sees.
19add56
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Eeee
I'd be curious to see what
parse_dammit
does too. I'd want to avoid leaving import/export around as much as possible as that will surely be the first fail masking others (imports are usually at the top). So maybe a hybrid of loose parsing and shallowing parse errors.