PHPUnit tests + Linting for WP plugin

[ashfame]

This PR sets up linting + phpunit tests setup for the WP plugin that would provide the REST API.

On local, it uses wp-env to run tests, so utilize containers.
On Github, 2 workflows have been defined, one for linting and one for running tests.

As of now, there is no build process for this plugin, but we can add copy over the setup we have from our other WordPress plugins so that they can be published to WP.org plugins repo directly. I have left a note in the readme for the same.

[psrpinto]

Nice, looks great!

I have a few suggestions, mostly related with directory structure.

I think that the plugin source could be directly under src/plugin/, without having an extra try-wordpress/ directory. The advantage of this would be that the directory structure does not depend on what the plugin is named. I think the plan is to rename the project to something else later, so that would require renaming the directory too. If there's no directory with the same name of the plugin, renaming the project/plugin becomes easier. It's also nicer IMO because there's one fewer directory levels to deal with when developing.

I think it's useful to think of this repository as one "thing" that is composed of a frontend and backend, instead of if being a repo that contains two separate projects. With that in mind, I think the configuration files (.wp-env.json, composer.json, composer.lock, phpcs.xml, phpunit.xml) could be moved to the root of the repository. This makes it possible to run commands from the root of the repo (e.g. composer install, instead of needing to go into the directory where the files are.

The same principle would apply to the readme.md of the plugin. I think that information could be in the main README.md at the root of the repo.

Concerning the tests, I think both the frontend and the plugin tests could be inside the /tests directory at the root of the repo. We could split it into two subdirectories (tests/frontend and tests/plugin for example). We could also move the bin/install-wp-tests.sh script to this tests/plugin directory.

[ashfame]

@psrpinto Thank you for your feedback! Good points & I agree with both.

I had them in consideration but at one point, I had to define the path as plugins/plugin/plugin.php which made me add the additional dir to avoid confusion. For adding composer stuff to root, I thought would be easier to get it at least working completely as a sub dir, but now with the reasoning you mentioned, I will go ahead and make changes so both frontend+backend are treated as one.

[psrpinto]

Looks great! I was able to run tests locally 👍

I took the liberty of adding a paragraph to the README.md about installing wp-env.

I noticed a couple of issues that are due to the vendor/ directory being under ./src/plugin:

1. The frontend build (npm run build) is broken because the build tooling is including JavaScript files from ./src/plugin/vendor.
2. The frontend build copies all files from src/plugin into the build directory, and then zips them so they can be downloaded by playground. Since there's a lot of files in vendor/ this has an impact on the build speed (important in development environments as the build is triggered when files change).

We could fix both issues above by moving vendor/ out of the src/ directory. If you would prefer to keep vendor/ in the src/ directory, we can look into how we can exclude those files from the frontend build process, I haven't looked into it, but I'm sure it can be done. I think however that the simplest solution would be to move the vendor/ out of src/, as it would probably just work with no changes required to the build process.

[ashfame]

I took the liberty of adding a paragraph to the README.md about installing wp-env.

Cool, thanks!

Ouch about the issues, but I think the vendor dir should be kept within the src/plugin since that's the top level dir from the WP plugin perspective. Moving that out, would require hackery on wp-env side for the plugin to find the dependencies its going to need (it currently doesn't have any so for this purpose of PR, we can also just get rid of it and handle afterwards). This would also keep the "build" aspect of the plugin relatively simple - run composer and zip a certain directory.

The frontend build (npm run build) is broken because the build tooling is including JavaScript files from ./src/plugin/vendor.

I think the js build should be less aggressive and exclude the plugin/vendor ?

2 -- impact on the build speed

I realize this is most impactful and a blocker. I think we need to differentiate between dependencies and dev-dependencies in the build process. Right now, we don't have any non-dev dependencies so "js build" process shouldn't even pick them, right?

Also, I think for js build, perhaps we should be using the built version of plugin itself, rather than the src/plugin. This would solve both issues and also keep it lean?

[psrpinto]

Moving that out, would require hackery on wp-env side for the plugin to find the dependencies its going to need

I see, makes sense. I will look into making the frontend build exclude src/plugin/vendor. This will fix both 1. and 2. from above.

I think for js build, perhaps we should be using the built version of plugin itself, rather than the src/plugin

I'm not sure I understand what you mean by built plugin, could you clarify?

[ashfame]

Does the frontend build include bringing the wp plugin into playground? If so, I guess right now, its just bringing over all the files it finds in there. vendor dir contents would differ for prod install and dev install, right, so either we use the prod build composer install --no-dev --optimize-autoloader in frontend build or we keep the plugin built that gets used, which won't have the dev dependencies so no composer interaction required.

[psrpinto]

Does the frontend build include bringing the wp plugin into playground?

Yep, this is how it's set up currently.

For now, would it be ok with you if the frontend build just completely ignores src/plugin/vendor? (This would be as if that directory does not exist, from the frontend build's perspective). Since the plugin code does not use anything from vendor/, it should work. If this works for you, I can adapt the frontend build so it ignores src/plugin/vendor.

[ashfame]

@psrpinto Yep, I am ok with doing that for now.

[psrpinto]

Cool, it's done, turned out to be simpler than I anticipated.