In a Bun monorepo, any folder can become a package via a config setting

[vjpr]

My ideal package manager is one in which defining an npm package is simply a matter of indicating that a single file or folder should be published as a package.

For most monorepos, decisions have to be made about the boundary of what is a package with a package.json file. What should be split off into a helper libary, framework, etc.

I think it would be better to control the package boundaries in a config setting. Allowing more flexible sharing of packages.

Usually you start with a monolithic structure like:

- monolith
  - package.json
  - tsconfig.json
  - src
    - foo
      - index.js
    - bar
      - baz 
        - index.js
      - bat
        - index.js

Now say you want to turn baz into a package:

• you must nest everything in a src dir
• add a package.json and tsconfig.json file
• add/install dependencies for baz manually
• delete dependencies from 'monolith, that only baz` needs
• usually, move the new package dir outside of its original package

This is a lot of manual work, and makes decisions about package boundaries sticky, and hard to change. This can cause a lot of unnecessary complexity if things are split to early, and incorrectly, making it hard to undo stuff. Also because it's hard to split things, some packages will end up with a lot of coupling when they should actually be split.

To solve this:

• All package.json files should be generated as needed. Nx uses a project.json file and has a task to generate them. Because Bun has control over the package resolver in its runtime, perhaps it wouldn't even need this package.json file to ever exist except when publishing.
• Dependencies should be implicit based on usages in files. Versioning would be the only issue. But often in a monorepo, you want to use the same version for each dependency because there are often compatibility issues. So these package versions should be tracked in a monorepo global config setting. If a separate version is needed, this exception should be made explicity in a central place. Sometimes certain packages have a bunch of peer deps that require their versions to be aligned. E.g. react and react-dom. You could create "dependency sets" to solve this.

E.g.

- packages
  - react
    - default: ^18
    - exceptions:
      - my-package-foo: ^17

- dependencySets

  // Applies to every package by default.
  - default
    - versions:
      - react@18

  // Indicate some packages use react17.
  - react17
    - versions:
      - react@17
      - react-dom@17
      - ...something else
    - workspace-packages:
      - my-package-foo

  // Indicate some packages use react16.
  - react16
    - versions:
      - react@16
      - react-dom@16
      - ...something else
    - workspace-packages:
      - my-package-bar

  // Allow a specific set of versions to be used for a specific package (`my-package-baz`).
  - my-package-baz:
    versions:
      - [email protected]
      - [email protected]

The point here is that you are setting exceptions, and the rest of the dependencies are implictly set to the default version ranges.

• You would also have Bun re-write imports if we need to publish. If bar wanted to be its own package, any workspace package that depended on it would rewrite to #monorepo/foo/bar/baz -> @org/foo.bar/baz/index.js.
  • But if Bun is being used, and the package is not being used externally, then this isn't necessary.

Advantages

• Easily deploy any folder/file separately with a single config setting without having to even create package.json.
• Easily change package boundaries.

Challenges

• IDE support
• Refactoring
• Tsconfig compatibility

The challenges are mainly around package-specific import aliases (package.json#imports). Because boundaries are not rigid, every path would have to be relative to the monorepo root.

• E.g. For internal packagae imports: #monorepo/bar/baz/index.js instead of #baz/foo.js (i.e. if bar was a package)
• IDE would have to know about this
• This is kind of like Java namespaces.
• Refactorings would need to change a lot more files. IntelliJ/WebStorm can already do this when tsconfig is present. For consumer packages, you usually would use a convention to name packages based on the folders they are contained in anyway. @org/foo.bar.baz/index.js. So same issue if you rename the package. And also reduces the chance that someone renames a package, but keeps an out-dated package name that no longer maps to the directory structure.

[Jarred-Sumner]

We definitely want to have good monorepo support and it's something we are thinking about but it will first be with bun install before the runtime