Handle ES6 syntax when inspecting AMD modules for npm imports #85
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I'm working on toy project where browser compatibility isn't a huge concern, so I've been playing with turning off most Babel transforms other than modules and experimental post-ES2015 stuff. This means debugging code in the browser looks more like what I actually wrote, and also has a positive impact on build times.
However, I found that doing this caused
ember-browserify
to stop finding my npm imports. After a little investigation, it turns out this is because the addon assumes any module that doesn't parse as valid ES5 must be using the modern module syntax.Sadly, since ES2015 module loading is one of the lingering features that hasn't achieved wide rollout yet, it's totally possible for code like this to trickle through the Broccoli pipeline:
It won't parse as valid ES5, but it also doesn't have any
import
statements in it, so the dependency on thesome-package
npm package is lost.The proposed change here abandons the first pass attempting to parse modules as ES5, and instead does a single traversal recording both
import
statements anddefine()
calls. In most scenarios you'd only ever see one or the other, but for consistency with today's behavior, if any ES6-style imports are found, those win out over anything that looks like an AMDdefine
.