`@nrwl/js` library generator has `includeBabelRc` option, but neither compiler option actually uses it

Current Behavior

When generating a buildable @nrwl/js library, includeBabelRc is a valid/documented option, with the following description:

Include a .babelrc configuration to compile TypeScript files

However, the compiler option for the same generator only has two options, tsc and swc, neither of which correctly support a .babelrc configuration (at least not that I could figure out — please correct me if I’m wrong about that).

Expected Behavior

• babel compiler option exists with matching executor, which uses Babel to build the project.
• Description for includeBabelRc generator option notes that compiler must be set to babel in order for this option to work as expected.

Workspace Description

My (tentative) goal is to use solid-js to build a library of native web components that can be shared with (at least) two applications, one of which is built with React, and the other with Elm. I’m trying to put together a minimal Nx workspace to prove out the concept. It has a library project that exports a single web component built with Solid, and a React application project that imports and renders it. However, I cannot find a suitable Nx executor to build the library with a custom .babelrc config. When I set up the tsconfig and .babelrc as advised by Solid’s docs, build the library with Nx, and then inspect the output in the dist folder, I’m seeing that the build process (with either the tsc or the swc executor) leaves the JSX markup completely intact instead of running it through the Babel transformers, which breaks the React app at runtime. (Unfortunately I’m not able to share the workspace for repro purposes, but I’d be happy to answer any specific questions you might have about my setup.)

Additional Context

Solid uses a Babel preset (or plugin) that compiles JSX expressions to native JavaScript code making use of its own rendering infrastructure. My theory is that its small size, excellent performance characteristics, and familiar ergonomics would make it ideal for this project, since the end result could interop with any web application with virtually zero overhead.

I know that I could go through the trouble of setting up some kind of custom build system for the library, but 1) that’s a lot of effort for a POC that I haven’t presented to my managers yet, and 2) it’s a little disappointing that Nx can’t do this out-of-the-box anymore. I’m as excited for swc as anyone, but it’s really not a production-ready replacement for Babel just yet. As I understand it, the upcoming v2 will be backwards-compatible with existing Babel plugins (at a performance cost, due to some limitations of the Rust<->JS bridge), but in the meantime swc only supports a limited subset of the most popular official Babel plugins/presets, which they’ve re-implemented in Rust.

[nartc]

@dannymcgee the includeBabelRc flag in @nrwl/js is to cope with nrwl/js:lib in a React-app workspace. If you use nrwl/js in a node environment or babel-less environment then includeBabelRc is there to prevent a babelrc file to be created.

The logic at the moment is to generate the .babelrc file if the generator detects nrwl/web in package.json. The consumers can override that by supplying --includeBabelRc explicitly

[dannymcgee]

@nartc Thanks for the explanation, that makes sense! I’m going to go ahead and close this since it sounds like this is working as designed.