Create a Proof of Concept Package for Deployment to all environments

[pablinos]

Is your feature request related to a problem? Please describe.

We currently have features on WordPress.com, that are not available on Jetpack/Atomic sites, and some that have copies of code in Jetpack or other plugins, which creates problems with maintenance and parity of experience.

Describe the solution you'd like

We would like to explore creating features as composer packages within the Jetpack repo, so that we can then require them as dependencies in different environments. These should ease deployment and ensure that we share as much code as possible.

Describe alternatives you've considered

We have discussed creating separate plugins, or building on top of other plugins that we use for delivering functionality to all site types, but given the tooling that's already available in the Jetpack repo, this seems like the most appropriate place for development.

Additional context

There is some initial work on this concept that has been done for Nav Unification in #19726

[jeherve]

There is some initial work on this concept that has been done for Nav Unification in #19726

There is also #19777 for another take on this.

I should also note that we have a generate command in the Jetpack CLI tool (reference) that will help you create a basic package and all its needs. That can be a good starting point when working on packages.

---

Previous conversations about this:

• pd2C0z-b-p2#comment-11
• p9o2xV-1um-p2

[retrofox]

There is some initial work on this concept that has been done for Nav Unification in #19726

There is also #19777 for another take on this.

Yeah, it will be a nice challenge to unify efforts here. From my PoV, we should try to increase the scope of the package.

[pablinos]

From my PoV, we should try to increase the scope of the package.

I think this could be a tricky balance to get right. If we kept the initial packages small in scope, delivering specific features, could we then create a unifying package in future which had those feature packages as dependencies? Or would that be over complicating things?

[retrofox]

From my PoV, we should try to increase the scope of the package.

I think this could be a tricky balance to get right. If we kept the initial packages small in scope, delivering specific features, could we then create a unifying package in future which had those feature packages as dependencies? Or would that be over complicating things?

Not at all. I think that approach could scale with a not big effort.

[pablinos]

Now I'm starting to wonder if we could have lots of composable packages that would allow people to build their own admin experience. I'm way in the clouds with that thought.

Let's see if we can get a feature package working how we like, either by creating a new one or building on #19726 or #19777

[retrofox]

let's close this issue. Reference pd2C0z-7K-p2

[pablinos]

Do you think we've proved concept enough @retrofox? Should we have a new issue for the post list enhancements that we're working on?

I think there are still some open questions around how we deploy the package.

[retrofox]

Not at all. Let me re-open it. I misunderstood the "next steps" that we were going to take.