-
Notifications
You must be signed in to change notification settings - Fork 0
Tools and decission making
WordPlate for repo organisation
When working in a team it is hard to have all instances of a project in sync. Multiple local sites, staging and live servers. On core problem is having the same plugin version on every instance.
WordPlate helps with that through enabling the use of composer for plugin management.
Alternatives would be: Roots Bedrock Roots Bedrock (which feels a lot more bloated in comparison to stripped down WordPlate), WP Starter (which seems very promissing but in between versions), SpinupWP Composer starter (which seems to bare)
WordPlate is well maintained and usually has zero open issues as the maintainer(s) answer lightning fast.
This is the standard.
This might change to yarn at some point. Yarn seems to still be better in a couple of things. Like faster speed, a bit simpler syntax etc. But Yarn 2 (Berry) seems to not really be liked by the community so far and Yarn 1 (classic) is not really developed any more as the focus is on Berry. We will check back on this in the future. Other alternatives like pnpn were not considered as we try to stay mainstream.
Check again around 2021-06/07
Tailwind CSS organisation
We try to go the tailwind route - which is, in a way, avoiding CSS organisation. Reduce naming hell and we hope to manage reducing CSS overhead as good as possible. We will see if we will need an aditonal paradigm as soon as utility classes reach their limit.
PostCSS for CSS optimisation
Tailwind recommands to use PostCSS for Tailwind handling. As PostCSS is widely supported (webpack, gulp, parcel etc.) we lean into PostCSS hard and will use it for prefixing (autoprefixer), minification, SCSS like syntax and all optimisations that can be handled via PostCSS
Modern sites are hard without JS. WordPress is still uses jQuery a lot and starts to use a lot of React for the backend. JS heavy sites are a modern aproach (eg. single site pages that rely heavy on React) but we rather try to go the static site route. Avoiding heavy frontend js frameworks is one key for that. Reducing the use of JS all together is a good idea. We try to focus on modern JS, in the best case don't use jQuery at all (which anyway often leads to hard to maintain js code) and lean into Alpine Js if needed. Similar to Tailwind Alpine code is directly added in the HTML code (which adds a bit of bloat there) and is easy to understand, fast to write and clear to maintain. We hope to keep the JS footprint slim and the site easy to maintain.
Going for PHP Standards
WordPress has Coding Standards that the core project follows and which are recommanded for plugins, themes etc. to follow. We will go for the PHP-FIG (Coding) Standards to stay more in line with the general PHP community and to be able to use standard tooling from the wider community. This also reduce necessary conversations to a minimum.
Prettier for Code Formating
We plan to use Prettier to help us have a consistant code formatation and make it easy to onboard people or allow cooperation. Coding style is not an hot topic this way. Using it for JS, PHP and CSS.
Git Hooks via Husky for automatisation
To make routine tasks easier and improve code quality we will automate certain things with git hooks via Husky. And NPM scripts.
Alternative: directly use git hooks (downside: not so easy with teams)
This decision is not the most clear. We will start with a Laravel Mix setup, which is a tool that builds on and simplifies Webpack. As soon as we go the next step of automatically optimize our builds we might change to standard Webpack or even go to gulp.
WPack seems very promissing. But we are not yet super convinced. It simplifies some things, adds complexity to other ends. And I fear a bit unnecessary increased complexity in the output.
It best case the build tool/asset pipeline is easy to replace.
Alternatives: Laravel Mix, Gulp, WPack
Timber as candidate for Templating
PHP was originally started as a templating language for HTML. But it grew big and reached a point were there were templating languages created for PHP. Timber is a tool for using Twig with WordPress. Twig is rooted in the Symfony project and is widely used and supported in PHP land. An alterntive would be Blade (as supported by Sage). Blade is quite a bit simpler than Twig and very popular in the Laravel world (where it is rooted at) but not very much used outside of it.
not yet decided
if there are multiple options that are similiar suitable, prefer:
- more popular tools (to have a greater community, more chances for support etc)
- the tool with better documentation
- the more current maintained tool
- a tool that works more generally (so we aquire knowledge that is also usable outside of WordPress, PHP, etc)
- more static results
In best case, a tool is easy to be replaced.