builder-bob unexpectedly ships multiple package.json files

[vonovak]

Description

0.27.0 is the last version that ships one package.json version file (in the root) of the build output. The following versions add more package.json files through 0c5582b and 5b45554

I find this somewhat unexpected and I'm wondering if this is necessary because various tooling (such as expo config plugins) assume presence of one package.json in the root. Fix for expo config plugin resolution is here but other tools might also be affected.?

As far as I know, other popular libraries like zod aren't doing it like that (while still dual-publishing CJS + ESM) https://www.npmjs.com/package/zod?activeTab=code

For reference I'm adding the spec link https://nodejs.org/api/esm.html#resolution-algorithm-specification though I'm not sure if there's part that multiple package.json files would violate.

This issue is a question of whether it needs to be done this way and also a heads up for maintainer so that you know some tooling might be incompatible with this approach.

Packages

• create-react-native-library
• react-native-builder-bob

Selected options

bob configuration: https://github.com/vonovak/react-native-theme-control/blob/93448d0744721219beed5d5ed9399dcbd7f5d548/package.json#L123

Regarding the repro: the linked version of the npm package has multiple package.json files that can be found in lib/commonjs and lib/module

Link to repro

https://www.npmjs.com/package/@vonovak/react-native-theme-control/v/6.0.1?activeTab=code

Environment

System:
OS: macOS 14.7
Shell:
version: 5.2.15
path: /opt/homebrew/bin/bash
Binaries:
Node:
version: 20.17.0
path: /opt/homebrew/bin/node
Yarn:
version: 1.22.22
path: /opt/homebrew/bin/yarn
npm:
version: 8.19.4
path: ~/_dev/_own/theme-control/node_modules/.bin/npm
Watchman:
version: 2024.07.01.00
path: /opt/homebrew/bin/watchman
Managers:
CocoaPods:
version: 1.15.2
path: /opt/homebrew/lib/ruby/gems/2.7.0/bin/pod
SDKs:
iOS SDK:
Platforms:
- DriverKit 23.5
- iOS 17.5
- macOS 14.5
- tvOS 17.5
- visionOS 1.2
- watchOS 10.5
Android SDK:
API Levels:
- "26"
- "33"
- "34"
Build Tools:
- 26.0.3
- 30.0.2
- 30.0.3
- 33.0.0
- 33.0.1
- 34.0.0
System Images:
- android-23 | Google APIs ARM 64 v8a
- android-24 | Google Play Intel x86 Atom
- android-26 | Google APIs Intel x86_64 Atom
- android-33 | Google Play ARM 64 v8a
- android-34 | Google APIs ARM 64 v8a
- android-VanillaIceCream | Google Play ARM 64 v8a
Android NDK: Not Found
IDEs:
Android Studio: 2024.1 AI-241.19072.14.2412.12360217
Xcode:
version: 15.4/15F31d
path: /usr/bin/xcodebuild
Languages:
Java:
version: 17.0.11
path: /usr/bin/javac
Ruby:
version: 2.7.8
path: /opt/homebrew/opt/ruby@2.7/bin/ruby
npmPackages:
"@react-native-community/cli": Not Found
react:
installed: 18.2.0
wanted: 18.2.0
react-native:
installed: 0.74.5
wanted: ^0.74.5
react-native-macos: Not Found
npmGlobalPackages:
"react-native": Not Found
Android:
hermesEnabled: false
newArchEnabled: true
iOS:
hermesEnabled: true
newArchEnabled: true

[satya164]

There are 2 ways of specifying the module type, file extension (e.g. .cjs, .mjs) or type field in package.json. The file extension approach has many problems, and it's not an approach we can even use with React Native. So we're left with the current approach.

You can read more details on full analysis of various approaches in my blog post https://satya164.page/posts/publishing-dual-module-esm-libraries

Tools like tshy do the same approach of shipping package.json with type in build folder https://github.com/isaacs/tshy?tab=readme-ov-file#package-imports, so it's not only code built with Bob that'll break.

If tools like Expo Config Plugin don't work correctly with it, then there is a bug in those tools and they need to be fixed.

While bob uses additional package.json files for type field, having multiple package.json files in a project is nothing new. It has been used to specify entry point for a very long time. Here's another example of multiple package.json being used for a package https://github.com/software-mansion/react-native-screens/tree/main/native-stack

Multiple package.json files may have been traditionally rare, but not entirely non-existent. So if a tool assumes a single package.json file for a package, it's inherently a faulty assumption.

[vonovak]

Thanks for clarifying! 👍