chore: Standardize NPM scripts across examples

[josephfusco]

As a Headless Toolkit contributor, I would like to see standardized npm scripts commands across the toolkit's examples in order to keep things simple.

Acceptance Criteria

• NPM commands are standardized across the examples.
• Readmes are updated to reflect adjustments

Notes

Dependent on #304

Consider following industry standards. What are patterns in similar projects?

e.g.

npm start

[ahuseyn]

For a comparison I'm posting two different versions of the package.json that the examples have:

• https://github.com/wpengine/hwptoolkit/blob/main/examples/next/template-hierarchy/package.json
• https://github.com/wpengine/hwptoolkit/blob/main/examples/next/custom-sitemap-apollo/package.json

Instead we can standardize the them by using the scripts below across all existing and future examples:

   "setup": // setup example,
   "dev": // start example,
   "stop": // stop wp instance,
   "clean": // remove wp instance and delete files,
   "wp:start": // start only wp instance,
   "db:import": // import db, in case you need to reset wp state or import new db,
   "db:export": // export db, in case you want to save wp state,
   "db:query": // db query helper to play around,
   "assets:zip": // zip the assets,
   "assets:unzip": // unzip the assets

It includes workflow scripts (setup, dev, stop, clean) and scoped scripts to provide granularity both for maintainers and for users.

The naming is consistent across other projects, so it's easy to grasp and scoped scripts are more simplified in naming.

For the environment variables, I'm suggesting to use .env.example instead of hardcoding the WP url, for promoting the best practices and habits. Right now some examples require user to create .env file and populate it by copy-paste. Other examples have hardcoded values.

.env.example would simplify the setup step as we can provide the default values without needing the hardcoded values and potential security issues for those who use our examples as a starting point.

@wpengine/headless-open-source let's agree upon these before moving forward to update all of the examples.

[alexwpengine]

Looks good and simple.
However there is a difference in "setup" in my examples and Alex Moon's. It only setups, it doesn't start the env and app. I think we should clarify it.

P.S. I see we also have slight differences in .wp-env.json, not sure if we want to cover in this issue for npm scripts.

1. WP_SITEURL & WP_HOME (127.0.0.1 vs localhost in apollo-authentication example) and different ports (my examples).
2. lifecycleScripts.afterStart

[moonmeister]

I like the idea of using .env.example with the suggestion that we add copying this to a working file to setup. This way there's nothing for the user to do but best practices are still used.

I think there is at least one missing command...maybe more. As issue I had was when you run start from the root it starts WP in the background and then the app is the foreground. Not an issue till you kill the process. You've killed the app but not WP. Running start again in slow cause it does WP things. I had added an app:start/dev script so I didn't have to switch to example-app folder to run that specific command. Or wait for wp slowness.

[ahuseyn]

Looks good and simple. However there is a difference in "setup" in my examples and Alex Moon's. It only setups, it doesn't start the env and app. I think we should clarify it.

P.S. I see we also have slight differences in .wp-env.json, not sure if we want to cover in this issue for npm scripts.

1. WP_SITEURL & WP_HOME (127.0.0.1 vs localhost in apollo-authentication example) and different ports (my examples).
2. lifecycleScripts.afterStart

Yes, as all the scripts have to do the same thing across examples, I'm thinking to make all of them to be like your examples. Setup is to setup and dev to start. It feels counterproductive to stop wp instance and then restart it again, but I'll research further to see if it's possible to import sql without starting wp instance.

[ahuseyn]

I like the idea of using .env.example with the suggestion that we add copying this to a working file to setup. This way there's nothing for the user to do but best practices are still used.

I think there is at least one missing command...maybe more. As issue I had was when you run start from the root it starts WP in the background and then the app is the foreground. Not an issue till you kill the process. You've killed the app but not WP. Running start again in slow cause it does WP things. I had added an app:start/dev script so I didn't have to switch to example-app folder to run that specific command. Or wait for wp slowness.

That's a good point, we can add frontend:dev script for that case.

[moonmeister]

app:dev might be shorter...or fe:dev

[ahuseyn]

app:dev might be shorter...or fe:dev

app:dev sounds good