Move Playground-based applications to dedicated repositories

[adamziel]

This issue exist to move the applications built with WordPress Playground to dedicated repositories to keep the WordPress Playground project focused on its long-term vision and to help applications built on the Playground to maintain their own faster iteration pace.

Related Pull Requests:

• Remove interactive-code-block from the main repository so it can live in a dedicated space. See #473. #475
• Remove VS Code extension from the main repository so it can live in a dedicated space. See #473. #476
• Remove wp-now from the main repository so it can live in a dedicated space. See #473. #477

Rationale

The Playground framework and projects built on the Playground have different needs, values, and philosophies. Separating applications from the main framework repository creates an environment that allows both apps and the framework to move at their natural paces, leading to more focused and efficient development.

Applications may prioritize attracting open-source contributions or they may be better-off prioritizing fast iterations by the core team. They may focus on extensibility or they may be better-off prioritizing features. They have varying needs in regard to coding standards, build tools, versioning schemes, CI processes, and project management principles.

Playground, however, have very specific priorities outlined in the vision. It aims to be approachable for new contributors, easy to maintain, and focused on foundational tools. It has specific coding standards, build tools, versioning scheme, CI processes, and project management principles. Every extra package in the Playground repo, no matter how great, makes the codebase a little bit more difficult to approach, adds a little extra time to the weekly maintenance, and makes the project a little bit less focused.

Therefore, it is for the best for WordPress Playground and the applications built using WordPress Playground to grow in a space that’s tailored specifically for their own unique needs.

Next steps

• Discussion and comments on this issue are welcome.
• The new https://github.com/WordPress/playground-tools repository was created as a home for the interactive code block. VisualStudio code extension may potentially be moved there as well.
• wp-now is also welcome to move to the above repository, unless the team behind it chooses a different one.
• GitHub issues related to each application may be transferred using the Transfer issue feature.

[danielbachhuber]

1. Should the VS Code extension live in its own repository too?
2. Who is maintaining each project?

[adamziel]

Should the VS Code extension live in its own repository too?

@danielbachhuber I remember you preferred to focus on the CLI tool and I'm happy to the VS Code extension in the https://github.com/WordPress/playground-tools repo for now.

Who is maintaining each project?

No changes there:

• Playground-specific issues would be tracked and addressed in the Playground repository by Playground core contributors
• wp-now would remain maintained by the same team as it now
• The interactive code block and the VS Code extension would be maintained in the tools repository by contributors of that repo (for now that's me)

[danielbachhuber]

A third question:

3. Should the VS Code extension share the same 'Mode' behavior as wp-now? https://github.com/WordPress/wordpress-playground/tree/trunk/packages/wp-now#automatic-modes

Playground-specific issues would be tracked and addressed in the Playground repository by Playground core contributors

For clarity, who is this? It'd probably be good to have a @wordpress/playground-committers or similar team: https://github.com/orgs/WordPress/teams?query=playground

[adamziel]

Should the VS Code extension share the same 'Mode' behavior as wp-now?

Is this relevant for the move? I'd like to keep this issue focused but we can discuss that separately in another one.

For clarity, who is this? It'd probably be good to have a @wordpress/playground-committers or similar team: https://github.com/orgs/WordPress/teams?query=playground

Communication around Playground governance will follow soon, this issue is about code organization. Is there anything specific you're concerned about?

Setting up a team sounds like a great idea 👍

[danielbachhuber]

Is this relevant for the move? I'd like to keep this issue focused but we can discuss that separately in another one.

Yes — it's a question of whether they share the same fundamentals or not.

Communication around Playground governance will follow soon, this issue is about code organization. Is there anything specific you're concerned about?

What will happen to the WordPress Playground codebase when you go on sabbatical.

[adamziel]

Yes — it's a question of whether they share the same fundamentals or not.

@danielbachhuber Modes specifically are a tough one because that’s still an open discussion. However, there’s a few other angles here:

• VS Code extension will need to be greatly adjusted to work with the in-browser version of VS Code, including removing the dependency on Node.js and any node imports (like fs).
• VS Code extension is meant primarily for a different audience – folks who are not familiar or not comfortable with the CLI. Their needs may or may not shape the extension differently than the CLI tool.
• VS Code extension can auto-update which means it has more freedom to bundle time-bound assets like specific WordPress releases.

I'd say let's separate them for now, see how that works for both, and pay attention to signs telling us to reconnect them.

What will happen to the WordPress Playground codebase when you go on sabbatical.

@dmsnell will tentatively shepherd WordPress Playground core while I'm away.

[danielbachhuber]

I'd say let's separate them for now, see how that works for both, and pay attention to signs telling us to reconnect them.

Sounds fine.

I think we should create entirely separate repositories for each codebase. Assuming the VS Code Extension gets a bit more traction, it will helpful to have a unique issue tracker.

[adamziel]

@danielbachhuber Thinking about this more, https://github.com/WordPress/playground-tools is just the interactive code block at the moment. I expect some activity there but not much. Moving VS code extension to that same repo will still give it an almost unique issue tracker while reducing the overall fragmentation.

If that becomes hard to manage for any reason, it will be easy to move it to its very own repo. It won't experience any core downsides in that repo, too, and will have its own versioning scheme etc. So almost all of the upside while reducing chores over multiple repositories. WDYT?

[adamziel]

I want to keep the momentum here so I'll go ahead and move it to playground-tools for now. I'm not insisting on this particular formula – let's keep talking and make another move tomorrow if needed. I just want to move it out of core and close this issue asap.

[danielbachhuber]

I think that they should either: 1) all be in the same repository, or 2) all be in separate repositories. I also think we should persist git history when we move them.

[dmsnell]

note that it's also possible to create a "grafted commit" in git so even if the code is copied raw, it can still refer to the source from which it came, preserving the history. this requires adding the link back to the original repo from which it was grafted.

[adamziel]

Let's do separate repositories, then. Which repo would you like to move wp-now to?

[sejas]

Is it a good idea to push the changes to Automattics's repo https://github.com/Automattic/wordpress-playground and then rename it to wp-now ?

[adamziel]

As @danielbachhuber pointed out in another conversation, keeping WordPress Playground code under the WordPress organization seems like the most natural choice.

I think that they should either: 1) all be in the same repository, or 2) all be in separate repositories.

Let's move forward with proposition 1) then. I just moved wp-now code to the https://github.com/WordPress/playground-tools repository in WordPress/playground-tools@bb00e26 where it lives alongside the VS Code extension.

This concludes moving applications out of the main Playground repo. If you'd like to house these tools in a different repo than playground-tools we can still do that.

[adamziel]

As for

I also think we should persist git history when we move them.

I included the link to the previous wp-now package in the migration commit. The grafted commit mentioned by @dmsnell should allow the consumers of the repo to connect that commit with the playground tree. Otherwise, if you know of any technique that would preserve the history in the GitHub web UI, please share and let's do it.

[wojtekn]

I also think we should persist git history when we move them.

Would it work to just copy the repository and remove whatever we don't need in the new one?

[danielbachhuber]

Would it work to just copy the repository and remove whatever we don't need in the new one?

Yes, this is what I was thinking and I think it would be preferable.

[adamziel]

That's a brilliant idea! The history is back @wojtekn @danielbachhuber : https://github.com/WordPress/playground-tools

[danielbachhuber]

That's a brilliant idea! The history is back

Measure twice, cut once 😊

[danielbachhuber]

I moved all of the Local Environment and VS Code issues to https://github.com/WordPress/playground-tools/

@adamziel As remaining cleanup, it would be nice to update https://github.com/WordPress/playground-tools/blob/trunk/CONTRIBUTING.md and make sure publishing works. Otherwise, things seem fine on my end.

[adamziel]

The CONTRIBUTING docs is now updated, let's close this issue and track anything else that might bubble up separately.