Monorep: lets move it all together

[wesleytodd]

As discussed on the package interop meeting, we thing we should move all the create- things into a monorepo here.

[wesleytodd]

Do we want to pick a particular monorepo toolchain?

[wesleytodd]

On the call we discussed using a few things. Turbo, npm, and Release Please specifically. Is everyone alright if we go that route for this proposed monorepo?

cc @Ethan-Arrowood @rxmarbles @lukekarrys

[ljharb]

I wasn’t able to make the call, but… why?

[wesleytodd]

I don't want to speak for @Ethan-Arrowood, but his feedback was that the current repo setup was unclear on what all the scope was and how things should fit together.

From my side I was thinking that we probably want to publish a small package per complicated package.json field which does validation and generation. I think that a monorepo setup would be ideal for that as well.

[ljharb]

That sounds like a very large architectural change that shouldn’t be made quickly and should be fully thought out before doing anything towards it.

[wesleytodd]

Agreed! We started with this issue to have that discussion. I was thinking we could also then have it on a package maintenance meeting. Does that work for you?

[ljharb]

Sounds good, thanks for clarifying.

I’d prefer to use npm workspaces if possible, so we’re using standard tools.

[wesleytodd]

Oh yeah, workspaces was a give imo and I think we all agreed. Unfortunately workspaces does not natively do the versioning and selective release stuff Release Please does and also doesn't have workspace orchestration stuff like turbo. I think those things on top of workspaces are where I think the meat of the discussion would be, but I don't think any situation would not be using npm workspaces.

[ljharb]

Automated releases are another discussion we’ll need to have, i think, and not a given.

[wesleytodd]

Agreed we need to have this discussion. That said, if you cannot tell I think it is really great with Release Please and some branch protections in place. Looking forward to the healthy debate 😆

[Ethan-Arrowood]

Yeah I'm already confused by the difference between the create and create-package-json repos and why there isn't a create-pkg one either. And based on the plan in #7 , we'll eventually have a ton of repos that will all need to have the same tooling copy-pasted over and over.

Monorepos are great in today's dev world (I acknowledge they weren't previously), and so we should adopt that pattern here since we are already planned to have multiple very similar packages. We definitely should start with standard tools.

[wesleytodd]

@ljharb we discussed this on the call today and are going to also try and get this topic on one of the next package maintenance working group meetings. What we decided today is that to get the ball rolling we would use npm workspaces, do manual publish, and keep it as simple as we could while still combining these create-* things into one location. I won't be working on this this week I don't think, and since I have been the primary person working on it anyway, it likely wont happen if I am not doing it (although anyone is welcome to!) so no rush to respond, but PMWG meeting isn't until the 18th it looks like so if I can make progress before then I would like to. Let me know what you think of that and we can close this out.

[rxmarbles]

Closing this as we have already begun this process and are now full monorepo

[lukekarrys]

@rxmarbles Was this meant to be closed automatically?