In an ideal world, it makes no sense for third parties to reimplement .babelrc lookups in their own tools, and I think that fact that it isn't uncommon points to missing features from babel-core. I think it is important that we, as a team, understand why that approach is currently taken by tools using babel-core so that we can ensure the babel-core API provides the primitives that third parties need.
The cases I know of:
babel-loader resolves .babelrc for cache invalidation purposesbabel-jest uses the file for cache bustingbabel-brunch is currently trying to use OptionManager to inject default behavior fornext.js previously resolved .babelrc and now uses the private config-chain API to decide when to inject a default preset vs rely on a user's local config
There may be other cases, but those at least make two points clear:
The second case I don't think we adequately expose currently. We have OptionManager but it's not a pretty API, and while it exposes the final config, it doesn't allow users to know if there was a config file, or if the config just came from the defaults. You can check if there a plugins/presets present, which may be enough in this case though, so I'd consider that an open question.
I'd be curious to hear from @arunoda since I've already had some back and forth about OptionManager in the Brunch PR, but the Next.js usecae is one I'm less clear on.
In an ideal world, it makes no sense for third parties to reimplement
.babelrclookups in their own tools, and I think that fact that it isn't uncommon points to missing features from babel-core. I think it is important that we, as a team, understand why that approach is currently taken by tools usingbabel-coreso that we can ensure the babel-core API provides the primitives that third parties need.The cases I know of:
babel-loaderresolves.babelrcfor cache invalidation purposesbabel-jestuses the file for cache bustingbabel-brunchis currently trying to use OptionManager to inject default behavior fornext.jspreviously resolved.babelrcand now uses the private config-chain API to decide when to inject a default preset vs rely on a user's local configThere may be other cases, but those at least make two points clear:
babel-coredoesn't expose caching primitives. We may be able to address this as part of RFC: Move caching from babel-(loader|register) to babel-core and plugin framework #5372The second case I don't think we adequately expose currently. We have OptionManager but it's not a pretty API, and while it exposes the final config, it doesn't allow users to know if there was a config file, or if the config just came from the defaults. You can check if there a plugins/presets present, which may be enough in this case though, so I'd consider that an open question.
I'd be curious to hear from @arunoda since I've already had some back and forth about OptionManager in the Brunch PR, but the Next.js usecae is one I'm less clear on.