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

Replace acorn parser for babylon? #71

Open
zdychacek opened this issue Jul 13, 2017 · 5 comments
Open

Replace acorn parser for babylon? #71

zdychacek opened this issue Jul 13, 2017 · 5 comments

Comments

@zdychacek
Copy link

zdychacek commented Jul 13, 2017

Hi,

I came across a problem when node-detective cannot operate on ES2015+ source code.

This is not a problem solely related to this package. The same problem applies to node-syntax-error package which is used in browserify pipeline.

I can see a clear problem in the fact, that some packages used by browserify internally depend on acorn parser.

This parser dependency is limiting e.g. for using browserify in conjuction with babelify in such situations when you don't want to transpile all the source code down to ES5.

For instance, let's say you don't want to transpile those syntax features, which are already natively supported by browsers, e.g. object spread operator in current Chrome. And now comes the problem with browserify syntax check and module dependecies parsing via module-deps -> node-detective dependency, all caused by code containing syntax features not parseable using acorn parser. It this case with ... operator.

Don't you think it would make sense to replace the parser and be more aligned with babel ecosystem?

Cheers,

Ondrej

PS: The same issue is being solved in these issues in Webpack project:

webpack/webpack#4308
webpack/webpack#2872

@zdychacek
Copy link
Author

Implemented in my fork: https://github.com/zdychacek/node-detective

I can create PR.

@casr
Copy link

casr commented Nov 11, 2017

node-detective has ES2017 support enabled already. On the specific point of object spread it is a ES2018 feature and only landed in Node 8.3.

Perhaps it would be simpler to just bump Acorn’s options to ecmaVersion to 9?

@zdychacek
Copy link
Author

@casr But what about non-standard features (stage < 4) which are already supported through Babel transformations?

Optional chaining operator and do expressions, to name a few.

@goto-bus-stop
Copy link
Member

I don't think browserify should support nonstandard features. You would not be able to use them anyway after bundling without first applying babel to the result, so you might as well use babelify first.

@goto-bus-stop
Copy link
Member

Note that most (all?) browserify packages now use acorn-node which has support for the latest features, and will match Node syntax with parser plugins if necessary.

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

No branches or pull requests

3 participants