Repository navigation
Follow-up work for compiling node_modules #3777
Description
Follow-up for #3776.
First thought: we should have an end-to-end test that depends on ES6 package (e.g. chalk@2.x). After the build, we can run ESLint in ES5 mode with no rules on the compiled bundle so that end-to-end test fails if we accidentally include ES6 code.
There may be more things we need to test. I’m not sure. Thoughts?
My original todos:
- Consider opt-out heuristics (e.g. "too old"
enginesfield that implies we don't need compilation) - Verify this doesn't break third-party code
- Decide on the behavior for
sourceType[8.x] Gain consensus on path forward for "sourceType" for parsing modules vs scripts babel/babel#6242
- Decide on the behavior for
- Verify generators and async/await work in deps
- Verify helpers for the above are being shared (e.g. runtime transform)
- Verify
.babelrcin packages gets ignored - Create end-to-end tests for these situations
Activity
[-]Add end-to-end tests for compilation of node_modules[/-][+]Follow-up work for compiling node_modules[/+]EnoahNetzach commentedon Jan 17, 2018
A couple of considerations/questions:
I propose we create a "fake" ES6 package crafted so that every main ES6+ syntax feature is certainly included.
The "too old" heuristic is to be done on the
node_modulesif I understood that right?In order to verify it doesn't break third-parties, we could just add an integration test that relies on the "fake" ES6 package, similarly to what we already do.
In order to verify that helpers are being shared, could a regex be sufficient? What if another dep ships with a copy of that helper?
gaearon commentedon Jan 20, 2018
Yes please.
Yes.
Yep.
I think it's okay to just verify this manually. I don't expect this to break once we make sure it works.
gaearon commentedon Oct 2, 2018
I don't think these are relevant?