-
Notifications
You must be signed in to change notification settings - Fork 61
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
Comments
Implemented in my fork: https://github.com/zdychacek/node-detective I can create PR. |
Perhaps it would be simpler to just bump Acorn’s options to |
@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. |
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. |
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. |
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 inbrowserify
pipeline.I can see a clear problem in the fact, that some packages used by
browserify
internally depend onacorn
parser.This parser dependency is limiting e.g. for using
browserify
in conjuction withbabelify
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 usingacorn
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
The text was updated successfully, but these errors were encountered: