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

Follow-up work for compiling node_modules #3777

Closed
7 tasks
gaearon opened this issue Jan 13, 2018 · 3 comments
Closed
7 tasks

Follow-up work for compiling node_modules #3777

gaearon opened this issue Jan 13, 2018 · 3 comments

Comments

@gaearon
Copy link
Contributor

gaearon commented Jan 13, 2018

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:

@gaearon gaearon added this to the 2.0.0 milestone Jan 13, 2018
@gaearon gaearon changed the title Add end-to-end tests for compilation of node_modules Follow-up work for compiling node_modules Jan 13, 2018
@Timer Timer added this to Blocker in 2.0 Jan 13, 2018
@EnoahNetzach
Copy link
Contributor

A couple of considerations/questions:

  1. I propose we create a "fake" ES6 package crafted so that every main ES6+ syntax feature is certainly included.

  2. The "too old" heuristic is to be done on the node_modules if I understood that right?

  3. 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.

  4. 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
Copy link
Contributor Author

gaearon commented Jan 20, 2018

I propose we create a "fake" ES6 package crafted so that every main ES6+ syntax feature is certainly included.

Yes please.

The "too old" heuristic is to be done on the node_modules if I understood that right?

Yes.

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.

Yep.

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?

I think it's okay to just verify this manually. I don't expect this to break once we make sure it works.

@gaearon
Copy link
Contributor Author

gaearon commented Oct 2, 2018

I don't think these are relevant?

@Timer Timer removed this from the 2.x milestone Oct 3, 2018
@lock lock bot locked and limited conversation to collaborators Jan 10, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
No open projects
2.0
  
Blocker
Development

No branches or pull requests

3 participants