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
Resolve .babelrc files in a monorepo. #4132
Resolve .babelrc files in a monorepo. #4132
Conversation
You goals make total sense to me, I agree that sub-projects babelrc files should be respected like the babel-cli does. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me, an integration test for this would be awesome
I added a unit test for the most complicated scenario (i.e. the one where you have to merge a @DeMoorJasper - let me know if you'd like to see any changes before the merge, or if there's any place where I can help with documentation. |
if (packageJSONPath) { | ||
let packageRoot = path.dirname(packageJSONPath); | ||
if (packageRoot && packageRoot !== options.projectRoot) { | ||
babelrcRoots.push(packageRoot); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We probably also need to track the package.json paths we searched as part of the config so it will be invalidated in the cache properly. Maybe a glob? cc. @padmaia
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh yeah, I guess that never got set. Easy to add though, it's just a call to config.setWatchGlob()
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure I fully understand how the cache invalidation works - could you elaborate on what you expect to happen (but isn't already), and how I might be able to test it?
In case it's relevant, one thing to note is that the sub-project babel config might be specified in a .babelrc
/babelrc.json
file in the sub-package directory, or as part of the babel
property of the package.json
file. Presumably, we'd want to make sure that the bundle will get regenerated if any of these change (and do whatever is necessary to keep the cache clean). Given this, are there any other tweaks you think might be necessary?
↪️ Pull Request
This PR contains a possible fix to #4120 (might also address one of the causes of #3917). The goal is to allow parcel2 to pick up configuration specified in
.babelrc
files in a monorepo.I wanted to make sure that the problem I experienced was considered holistically (taking into account all the likely ways that babel users are used to specifying configuration). As it turned out, that was kind of complicated, so I made a detailed explanation here:
https://astegmaier.github.io/parcel2-monorepo-babel-bug/parcel-goals
I'm putting this out there for early feedback. Specifically:
babelrcRoots
property of the babel api. The code I wrote makes calls to the file system each time a file's config is desired. I wonder if this information might be cached (maybe it already is, and I didn't realize how to access it)?Unit Tests - I would love some pointers about how/where to do this, patterns to follow, and how much of the scenario list you think is important to unit test.Edit (2/24): This is done.💻 Examples
The main goal is to make sure that Parcel2 will pick up
.babelrc
files in sub-projects of a monorepo. For example, if you have a project like this......things will work.
🚨 Test instructions
See this test repo for an environment where you can see the issue and test out the changes.
✔️ PR Todo
Closes #4120