[techninja1008]

Hi all. Put this together as I felt trunk lacks a good way to extend the build process with extra steps. I'm aware #104 includes a longer-term vision for a plugins system, but simple command-line hooks should provide for many use cases (including mine) for now.

Currently, this PR only includes the feature as-is and an extra example (yew-tailwindcss) that showcases it in order to produce a custom tailwindcss build that is pruned to only include classes used by the example. I'd like a bit of feedback on the design before completing the checklist below.

Checklist

• Updated CHANGELOG.md describing pertinent changes.
• Updated README.md with pertinent info (may not always apply).
• Updated site content with pertinent info (may not always apply).
• Squash down commits to one or two logical commits which clearly describe the work you've done. If you don't, then Dodd will 🤓.

[thedodd]

@techninja1008 I'm pretty happy to see this as I was just hacking on the WASM plugin system and was trying to think of use cases which did not involve simply moving some of our current plugins into WASM modules.

I'll give this PR a review ASAP and see if I can comment on the design a bit.

[techninja1008]

@thedodd I've tried to keep it purposefully simple but with scope to expand if needed. In particular, I've only added one point that hooks are called currently, but more can be easily added.

[thedodd]

Overall, I think this is put together quite nicely. I think this is an excellent precursor to the plugin system.

Design Thoughts

Firstly, the simplicity of the design is great. Just provide the name of a target (like sh in this case), and arguments to be supplied.

• Env vars which can be used in the hooks section, I like it, let's just pin down what they should be, and if we should add some additional env vars. Let's add docs for them as well.
• Stages, I'm thinking that we actually have 3 stages: pre-build, build & post-build. The example in this PR would land in the post-build stage.
• Long-term, we could add a custom stage which would have a name & allow for a list of before strings, where each before value would be a built-in or custom stage which must be executed prior to this custom stage being executed.
• Maybe we should change the name of HookStage to PipelineStage so that we can use it for the plugin system as well when that lands (or maybe just add a comment about that :)).

Items To Do

• We should add documentation on how this system should work.
• The docs should probably be added to the Assets page of the site.
• Perhaps some of the stage-related changes mentioned above and inline.

Long Term

We can probably have the plugin system work exactly the same way in terms of stages & when they are spawned.

Really excellent work here! I'm stoked to see how this evolves.

[thedodd]

Probably need to update the name here to yew-tailwindcss, and feel free to use your name as the author :).

[techninja1008]

I'm updating the name to be in line with the other examples (ie. yew-tailwindcss-example). I'm just wondering if it's worth removing the authors field altogether as that's the direction convention seems to be moving in? (see rust-lang/cargo#9282) I've changed it to my name for now.

[techninja1008]

I've just pushed a load of changes. I've tried to address every point here, including adding more env vars, modifying the hook (now called pipeline) stages, and documenting everything. Not yet added changelog entries, will do that when you're happy with it!

[techninja1008]

@thedodd just rebased to master & added changelog. Ready for review & merge if you're happy.

[techninja1008]

@thedodd just resolved the outstanding merge conflicts

[thedodd]

Well crafted PR! Thanks again @techninja1008. I'm going to merge this, and then fix the two small typo items & the CI linting issue from CI.

[thedodd]

I'll de-dupe this stage stage after merge.

[thedodd]

Top-notch docs right here. Thank you!