What is the point of building the Javascript for third parties react-native library maintainers ?

[fdrault]

Looking around third parties react-native library, most of them build the TypeScript/Javascript in a dist or lib folder, but I don't understand why. It might be because of create-react-native-library and react-native-builder-bob being very popular for library maintainer.

If your library need to be compatible with web (React App or simply js), then it is expected for third party maintainers to provide optimized JS bundle.

But what is the point to ship transformed js for React-Native ONLY library ?

There are many caveats to that

• Developer experience is bad. If you need to log or change something inside a library, you have to patch the node_modules and build it again. Sometimes, the npm packages does not come with sources, so you have to checkout everything or edit minified JS.
• When using your favorite IDE to see the library implementation, typescript definition file .d.ts will be separated from the lib code, even if the package is written in TypeScript
• (New arch) Codegen use source file so you have to publish part of them anyway
• Babel seems to transpile already transpiled code (not sure about this) so what is the point of doing it beforehand, and doing the job twice ?
• The "react-native" key in package.json is used as entry point for Metro, and most of the time, it points to the source code so, lib (bundled) files can be ignored and it becomes difficult to understand what is really in our final bundle

I did not find much documentation on that topic, is there something I am missing ? What is your recommendation ?

The only pro I have for shipping a react-native library with CommonJS support is for Jest, because you might need special configuration (or use ts-jest) when importing typescript code. Since TypeScript is the new default configuration for new react-native app, using jest with typescript will be more common.

[satya164]

This is mentioned in https://github.com/callstack/react-native-builder-bob#why-should-i-compile-my-project-with-react-native-builder-bob

To summarize:

• When supporting multiple platforms, pre-compiling the code is necessary to make it smoother for the consumer so they don't need to configure every tool to compile the code (Jest, Webpack, Node for SSR etc.) and their Babel config also needs to be the same or behaviour could change.
• Even if you only build for Android & iOS, metro isn't the only bundler that processes your code. Users write tests in Jest or another tool that runs in Node and Jest doesn't compile node_modules without configuration.
• Eventually, bundlers can take advantage of this to skip compiling this code to make things faster. @EvanBacon already did some work regarding this at Expo.

I don't think there are any significant downsides to ship precompiled code given that it can make user's experience smoother by avoiding additional configuration and enables tools like Expo to make builds faster by skipping the compilation step altogether. It's not something strictly necessary, but anything that improves DX is a good thing.

Developer experience is bad. If you need to log or change something inside a library, you have to patch the node_modules and build it again. Sometimes, the npm packages does not come with sources, so you have to checkout everything or edit minified JS.

The default setup in Bob publishes the source code as well. Not shipping the source is a deliberate decision by the library author so I think even if the default setup didn't have that, they'd configure it anyway.

When using your favorite IDE to see the library implementation, typescript definition file .d.ts will be separated from the lib code, even if the package is written in TypeScript

The default setup in Bob also ships declaration maps so this shouldn't make any difference. This is also not a problem unless someone is accessing private files that they aren't supposed to.

Codegen use source file so you have to publish part of them anyway

Ideally, codegen would generate the bindings before publishing, instead of on the user's machine. Generating code on the user's machine has many issues but that's a separate topic.

[fdrault]

Thank you for your complete answer.

The default setup in Bob also ships declaration maps so this shouldn't make any difference. This is also not a problem unless someone is accessing private files that they aren't supposed to.

In my experience, lots of packages get outdated, it is hard to get your pull request merged, patching or adding feature is a commun task in react-native ecosystem. For my usage, pre-compiling is a burden, since you have to edit multiple files, understand how it is build, depending on how the library is shipped (bob giving a pleasing standard on that).

Nevertheless, making integration easier is our ultimate goal, tools and usage might expand as well, so I understand your recommendation better.