canonical composer packages for plugin and theme

[chris montgomery]

Hi @gregrickaby, first off, thanks so much for your hard work on this project! It truly shines as one of the best starter projects for Next.js+WordPress.

As a new adopter, I have a question or potentially a request about the required plugin and theme:

Considering that those two Composer sources live inside the monorepo, it means that they must be kept in the source tree once a project has been bootstrapped from your repo. However, that means that they will no longer receive updates from upstream after the point of cloning. Since it seems very unlikely that I will want to change these packages, I would consider them must-use external dependencies that I have to keep around untouched unless I see an upstream change has been made, which kind of defeats the purpose of using Composer for those two, IMO.

I noticed that the plugin and theme also live in separate repos, but I am hesitate to switch over to point to those since it’s unclear which set of sources should be considered canonical and receive updates.

So my request goes something like:

• Remove the plugin and theme from the monorepo
• Point the Composer manifest to your other repos
• Explain the source relationships in documentation

Considering their simplicity I can totally understand if they are never updated. But say for example you or I find a bug - the monorepo could be updated with a patch, however no existing clones would receive the update to the template.

If that doesn’t sound like a preferable approach, that’s fine with me, though I would still like to hear your thoughts and intentions around the existing different plugin sources – i.e. why two separate sources now?

Thanks for your consideration!

[Greg Rickaby]

@montchr 👋🏻

Thank you for acknowledging the simplicity of this project. With a wealth of experience on headless WordPress projects, I know that it's not always easy to keep things straightforward. Unfortunately, excessive abstraction can often lead to complex, multi-layered systems that make it difficult to get started and even harder to customize to fit a project's specific needs. My intent with this project was to keep things as simple and straightforward as possible. 😄

First let me explain my reasoning behind each composer.json:

.
├── apps
│   └── wordpress
│       └── wp-content
│           └── composer.json  <-- The glue that holds the entire WordPress stack together. Points at the `packages` dir in this monorepo for the plugin/theme.
├── packages
│   ├── nextjs-wordpress-plugin
│     └── composer.json <-- Informs Composer in /wp-content what "type" of package this is. The type determines where it is installed.
│   ├── nextjs-wordpress-theme
│     └── composer.json <--  Informs Composer in /wp-content what "type" of package this is. The type determines where it is installed.
└── composer.json <-- A shared "engine" for linting all PHP in this project.

Next I want to go into a little history about why both the nextjs-wordpress-plugin and nextjs-wordpress-theme do not have their own repositories on Github/Packagist. My experience at WebDevStudios managing the headless core plugin, theme, and all the add-ons for their Next.js WordPress Starter was poor at best. Out-of-the-box, Packagist requires unique repository URLs for package, so it literally cannot "deal" with a monorepo unless you do something like this.

Based on that stressful experience, and for the sake of keeping this repo simple by not having to manage multiple PHP packages with a package, I opted for KISS, thus the plugin/theme here in this monorepo.

You are 100% correct in that now means keeping current with upstream changes will be challenging. I am very much open to suggestions and contributions on how to improve.

Thanks again for the note, it's appreciated and it is always great to hear from others! 🍻