RFC: Removing our disparate styles/javascript and installing govuk-frontend as a dependency

[kbayliss]

When tbxforms was created, we copied all of the GOV.UK Design System ("GDS" here on out) styles and javascript from the govuk-frontend package and diligently renamed them from govuk-... to tbxforms-... (e.g. govuk-clearfix became tbxforms-clearfix), as well as the odd minor tweak here and there.

This was a huge task.

The intent was to give us more control over behaviour and customisations, allowing us to make changes to better support our projects without waiting for updates to the GDS. However, in the two years of tbxforms being alive, no changes have been made to our styling or behaviour - no customisations have been made beyond what GDS already supports.

As a result, our styles and javascript are now significantly outdated and missing numerous fixes and improvements that have been made to the GDS over the past two years. This is primarily because porting the updates to tbxforms is arduous.

As a result, tbxforms is no longer the best it can be for usability/accessibility and is no longer compliant when used on GOV.UK projects - a big issue.

I propose we:

1. Install the govuk-frontend package and use the styles and javascript from there
2. Remove our tbxforms styles and javascript (excluding any additional styles we've added, such as conditional fields)
3. Update our templates to use the govuk- classes

This approach mirrors what crispy-forms-gds do.

The key advantages of doing this are:

• Maintaining tbxforms would be significantly simpler and easier.
• Upstream changes from govuk-frontend can be installed/updated independently of tbxforms (if govuk-frontend is installed at the project-level instead of tbxforms package level).
• We can access the upstream fixes and improvements from govuk-frontend, which is in active development.
• The GDS-flavour of wagtail-kit is simpler as the same variables can modify both the GDS and tbxforms.

This would still permit us to customise everything we can currently via SCSS variables.

There would still be the need for a tbxforms Node package as we have added additional behaviour for conditional fields, though the size of this package would drastically reduce.

[thibaudcolas]

I like the idea of simplifying the maintenance but I’m not sold on this being the right tradeoff. A fundamental problem with what you suggest is that tbxforms is only about forms, while govuk-frontend is a full front-end framework.

we copied all of the GOV.UK Design System ("GDS" here on out) styles and javascript from the govuk-frontend package

I don’t think that’s what happened. From what I can see:

• We copied 0 JavaScript from GDS. AFAIK our JS is only the 200 lines for conditional fields. The govuk-frontend ships with 600KB of JS according to my file system (60kb minified according to Bundlephobia).
• For CSS, we only copied the styles needed for forms-related components. From what I can glance this is only about a third of what’s included in govuk-frontend.

The intent was to give us more control over behaviour and customisations, allowing us to make changes to better support our projects without waiting for updates to the GDS.

Based on my points above – I assume this was also so we could avoid including the whole design system on our projects, and instead only reuse the form styles.

is no longer compliant when used on GOV.UK projects - a big issue

What is the compliance issue exactly? I’m not aware of GOV.UK projects mandating usage of GDS or a specific version of it.

---

The solution to my concerns above would be to only load the relevant subset of govuk-frontend, however even then I find this unappealing for a few reasons:

• It’s a 5.5MB package to install no matter what – and of those 5500KB (!), we only need about 100KB at most for the form styles – 2%.
• We have no reason to believe govuk-frontend Sass code would be authored so form components work correctly without other aspects of the framework in place.
• Sass isn’t a good language for design system reuse, if Sass stylesheets in govuk-frontend aren’t compatible with the Sass version we use on projects, we have no recourse (@use, math.div).

So at least based on this, I’d recommend we give further consideration to alternatives that simplify maintenance without throwing away the benefits of having our own package. For example it feels like rewriting class names to use govuk- would be a quick win.

[kbayliss]

Closing this as the primary driver (to make maintenance easier) has been addressed in #80

Thanks for guiding me, @thibaudcolas 🙌