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

[v0.37] Full deprecation of .babelrc.js #3245

Closed
thedavidprice opened this issue Aug 17, 2021 · 2 comments · Fixed by #3719
Closed

[v0.37] Full deprecation of .babelrc.js #3245

thedavidprice opened this issue Aug 17, 2021 · 2 comments · Fixed by #3719
Assignees

Comments

@thedavidprice
Copy link
Contributor

Continues work from #3231

Current implementation that shipped with v0.36:

  • only applicable to API, i.e. api/.babelrc.js
  • deprecates but does not throw or warn if file exists in an app

From Peter P:

I want this to be a breaking change if you have custom babel transformations. The reason I want it to be a breaking change is because I want to discourage people from adding their own babel transformations because I would like to move our own transformations to a faster toolchain and would not like babel to make that process difficult.

Next Steps

  • Full deprecation: required to delete api/.babelrc.js and/or to convert it to api/babel.config.js and remove the "extends" part.
  • Add tests:
    • Test that /.babelrc.js is not imported
    • Test that /babel.config.json can be imported if it's available.
  • Resolve conversation here about rw alias plugin and supporting custom aliases: https://github.com/redwoodjs/redwood/pull/3231/files#r687869806
  • TBD: also include Web web/.babelrc.js?
@peterp
Copy link
Contributor

peterp commented Aug 18, 2021

We use babel in 3 different scenarios:

  1. Pre-build: we transpile the magic out of the code, and turn it into ordinary JS code.
  2. Type generation/ Babel plugins: we "read" the user's source code to determine what's inside some file: Is it a Cell? Is it a directory-named-module? Does it have exports?
  3. Real-time run-time transpilation of files: We convert your TypeScript code into beautiful runnable JavaScript code in memory (in the same node process). We use this for pre-rendering, "console", and data-migrate.

Each one of these functions need to use ✨THE SAME CONFIGURATION✨ because if we're doing one thing in pre-build and another in real-time... People are going to loose their minds. If we don't loose them first... I'm taking mutiny. I'm talking "let them eat cake."

So... I propose that we come up with unit tests for the functions above that confirm we're not modifying their configuration in ways that make them inconsistent with each other.

@thedavidprice thedavidprice moved this from In progress (priority) to v0.37 in Current-Release-Sprint Aug 23, 2021
@thedavidprice thedavidprice moved this from v0.37 to Needs Discussion and Prioritization in Current-Release-Sprint Sep 10, 2021
@thedavidprice thedavidprice moved this from Needs Discussion and Prioritization to v0.38 in Current-Release-Sprint Sep 20, 2021
@thedavidprice thedavidprice moved this from v0.38 to Needs Discussion and Prioritization in Current-Release-Sprint Sep 28, 2021
@thedavidprice thedavidprice moved this from Needs Discussion and Prioritization to v0.38 in Current-Release-Sprint Oct 13, 2021
@peterp peterp removed their assignment Nov 3, 2021
@thedavidprice
Copy link
Contributor Author

@dac09 nudge on this one, high priority for v0.39

@thedavidprice thedavidprice linked a pull request Nov 10, 2021 that will close this issue
20 tasks
@thedavidprice thedavidprice removed this from v0.39 (locked) in Current-Release-Sprint Nov 10, 2021
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

Successfully merging a pull request may close this issue.

3 participants