Update GitHub and Bitbucket build pipeline

[eliot-akira]

This pull request updates the GitHub and Bitbucket build pipeline to run:

• https://github.com/tangibleinc/pipeline

It creates a zip file using roll archive for every version tag, and preview release on every commit. For now the Bitbucket pipeline is more feature complete: on new version it deploys the built plugin to the update server.

In a related change, when the Fields module is run as a plugin, it now loads its own Framework and Updater module. That way the packaged plugin works independently. I also added a script to update the version number in several files by running npm run version.

While testing it I updated the local dev site setup, including NPM dependencies. That's a bigger change than I had planned but hopefully it's OK, all tests are passing.

[eliot-akira]

To give more context - this is part of a larger effort to organize the Tangible Blocks suite of plugins and modules, so they all use the same setup.

• Framework for commonly needed features
• Roller to build assets and create zip archive
• Updater and Update Server
• Local dev site with wp-now and optional third-party plugins
• End-to-end test with Playwright
• Build and release pipeline on GitHub and Bitbucket

---

There's also a new architectural pattern I'm figuring out for plugin and module dependencies.

• A plugin installs and loads all required modules from vendor/tangible, including module dependencies (for example, how Fields depends on Date module in the Framework).
• A module lets the parent plugin load its dependencies, except when the module is run as a plugin during local development or as preview release; then it's expected to install and load its deps from its own vendor folder, same as any other standalone plugin.
• If possible, allow plugins to be loaded as modules, so they can run from inside vendor/tangible and share common modules like Framework.

I'm starting with the Template System and Fields module, then will update L&L and Blocks plugins that depend on them. During the process I'll write things down as documentation.

---

You can see the pipeline is already working with each step logged:

• https://github.com/TangibleInc/fields/pull/3/checks

And the preview release of this pull request branch:

• https://github.com/TangibleInc/fields/releases/tag/latest

---

(FYI @lloyd-teamtangible)

[nicolas-jaussaud]

Thanks a lot for the information about the new architectural pattern!

I would have a question regarding how we are going handle the dependencies going forward

Looking at the new example-plugin repository, I noticed that we don't have a composer.json file so I understand that we will not use composer anymore for internal dependencies (as everything will be installed from npm install)

Currently in fields, we have our internal dependencies set both in composer.json and inside the tangible.config.js file

Does that means I can safely removed our internal dependencies from the composer.json, or is it still going to be needed?

I'm also curious about external dependencies (phpunit for example). Is it also something we should try to install from the roller when possible, or is it fine if we stick to composer for those cases?

[eliot-akira]

I understand that we will not use composer anymore for internal dependencies (as everything will be installed from npm install)

Well, I would like to make Composer optional, not required but still supported. Composer and PHPUnit are not yet integrated with the wp-now setup, so I want to keep existing workflow and tests working with wp-env until the new setup is more mature.

I can safely remove our internal dependencies from the composer.json?

I think so. Roller installs dependencies as Git repos (or extracted zip) in the vendor folder, so existing code and tests should work the same. PHPUnit and polyfill can stay in composer.json.

An advantage of making PHP and Composer optional is that it simplifies project requirements and the build pipeline, so only Node/Bun and Roller are needed to install dependencies, build project assets, serve local dev site, run tests, and create zip archive for release.