Exposing Gatsby's Babel configuration would allow Gatsby apps to integrate with 3rd party tooling like linters and testing frameworks. There are two options for accomplishing this, making Gatsby's config a babel preset, or printing a .babelrc file in root of project (or somewhere else).
Currently getting testing or linting configuration requires essentially copying what Gatsby does into your own .babelrc file, at this point it would be much cleaner and easier on the user to just install and include babel-preset-gatsby.
oh yeah, just noticed this when I was working with Jest tests on a Gatsby site. I wondered if my babelrc I created for Jest was basically duping something Webpack is already doing?
Related https://github.com/gatsbyjs/gatsby/issues/5824
After the upgrade, Gatsby which now depends on Babel 7, will now reflect Babel's configuration resolution behavior, which will now defer to the consuming project's top level .babelrc instead, which generated this error
Yeah, I think it makes sense expose it as a preset so it's really easy to configure with tooling. I hit issues with Storybook as well.
Yeah, same here. Some tools require babel-config available like babel-plugin-react-intl. The same if I wanted to create my own tool that relies on babel and I don't necessarily want it in my build system (by extending webpack config).
I see that most of examples and even documentation suggests copying specific presets and plugins. But this is less than optimal and more like a workaround I believe. It will make harder to migrate app to newer versions. Specifying packages in config that are not installed explicitly by user is also fragile I think.
What I would ideally see is something like they do in NextJS. If you want a custom .babelrc you create a file with a nextjs preset which has all that is necessary to work by a framework:
.babelrc
{
"presets": [
"next/babel"
]
...
}
Agreed, this would be super useful! Setting up Jest in my project has been a pain and this would help streamline things while also being more explicit about what is happening behind the scenes. ๐
V2 is being released shortly and there are a lot of new docs that explain how to set up jest for testing! I would recommend going that route as we experimented with exposing config but it actually becomes harder to work with as you can't get the babel config until gatsby develop is running!
@kkemple I have to say I still find the docs confusing. It's unclear what approach should be taken if we just want to add a babel plugin. The old recommendation was to copy Gatsby's babelrc to the root and make changes there, but how should we be doing it now? How should we add a single babel plugin, for example babel-plugin-styled-components? Secondary to this, if we are modifying the babel config, how will this effect the approach to testing outlined in the docs.
@kkemple I echo the concern brought up by @Undistraction.
@Undistraction do you want to add the babel plugin to your testing config or to gatsby's build itself?
If for testing you would add that to the jest-preprocessor config you create, if for gatsby itself you would use the babel config API.
The reason exposing the actual babel config is difficult is because of the plugin architecture. Any plugin can modify that config, so in order to get a proper babel config you would have to run develop or build to first get all plugins and config bootstrapped then print out the babelrc file.
The other issue this opens up that in babel 7 a babelrc file at root of project will be read in by gatsby, so if you add a plugin to your now printed babelrc file then gatsby will use it during builds. If you still want to print it out you can do something very similar to this plugin.
Love this issue. I'll provide some context if someone wants to grab this for Hacktoberfest or honestly, just in general.
Expose an NPM package babel-preset-gatsby, that will be usable standalone (i.e. in Jest tests) and is also used internally so we get benefits "for free" as changes are made to that package.
packages/packages/babel-preset-gatsby package (use another package, e.g. packages/gatsby-dev-cli for a simple example of project structure, babel setup, etc.)As always, feel free to reach out to any of us on the Gatsby team for more assistance and detail ๐ ๐
@DSchau Thanks for your awesome write-up. I started with this in #8724. Would be great if you can take a look. ๐
Closed in #8724
Most helpful comment
Yeah, same here. Some tools require babel-config available like babel-plugin-react-intl. The same if I wanted to create my own tool that relies on babel and I don't necessarily want it in my build system (by extending webpack config).
I see that most of examples and even documentation suggests copying specific presets and plugins. But this is less than optimal and more like a workaround I believe. It will make harder to migrate app to newer versions. Specifying packages in config that are not installed explicitly by user is also fragile I think.
What I would ideally see is something like they do in NextJS. If you want a custom .babelrc you create a file with a nextjs preset which has all that is necessary to work by a framework:
.babelrc