Thinkmill/monorepo

Scoped vs unscoped packages in a monorepo

Closed this issue · 5 comments

Noviny commented

This is an issue based on some recent experiences that I wanted to make a guideline around.

Basically, if you have a multi-package repo and you have packages that aren't in a single shared scope, you can fail to give someone publish permissions. Combined with changeset's smart versioning, this can allow you to publish packages to an invalid state (depending on other packages that failed to publish)

I want to make a rule: "When publishing from a multi-package repository, make sure all packages share a scope - this ensures that anyone with permission to publish some packages should have permission to publish all packages, and avoid broken publishes"

Thoughts?

emmatown commented

I agree with it in general but we should probably be clear about saying that there are exceptions. For example, if you want a package named create- so it works with yarn create and npm init, that can't be scoped. Also, there are generic packages that might be better not scoped because they're generic and intended to be used outside of the repo, e.g. get-workspaces.

Noviny commented

legit use-cases why not this

It's a very meh balancing act IMO. Will make a PR with suggestions since we're broadly in agreement.

I think guideline is:

  • all packages live under one scope
  • create packages cannot be scoped and may live in the repository
  • In rare cases, you may want other packages that are developed alongside these but don't belong within the scope (I'd probably argue that these should still end up scoped, once again because it lowers permission sharing)

Heck, maybe it's 'all packages aside from create should be scoped'?

  • 👍1
Noviny commented

Random followup thought to add to this I'm just jotting down before I forget:

All packages in a scope should be in a single monorepo

lmk if that is controversial

Noviny commented

I just want to add a new addendum to this. When we build tools that allow you to target packages (if we do that) allowing people to target pacakagename with or without scope would be aces.

Example usage would be if we have a manypkg add command that could target, ie:

manypkg add react --to=@keystonejs-alpha/core

(yes bad syntax )

let you also run

manypkg add react --to=core

This works because in a single-scope world, these should be unique enough names.

Noviny commented

Merged the rec, closing the ticket