Version 2 changes

[ediblecode]

Ideas and discussions points for a version 2.

Please either:

• Add to the comments for each point below
• Or add a new point for discussion in the same format.

[ediblecode]

Brand refresh

Brand refresh including new typeface and colours will be a breaking change so an form part of a v2 release

[ediblecode]

This could probably tie nicely into design tokens (@barkertron you were interested in this) along with proper scss modulse (#264 (comment))

[ediblecode]

TypeScript everywhere

Currently we write components in ES6 with manual type definitions. This was an iteration on just pure ES6 and has worked well for allowing us to use TypeScript in apps like CKS/BNF. However, we always knew this was a temporary solution and we'd like to author components and tests 'properly' in TypeScript.

[ediblecode]

Icons

Our icon font and SVGs have worked quite well for use declaratively (for use in WYSIWYG pages in Orchard) along side SVG usage in React-based projects like BNF or CKS. However:

• they're generated with grunt-webfont which is an outdated tool that only works on Node 12
• they also don't ship with type defs, so we end up doing things like this in each project: https://github.com/nice-digital/bnf-gatsby/blob/main/gatsby/nice-icons.d.ts which is far from ideal
• the browser support for web fonts etc has changed and there's less no need to generate eot/svg/ttf web font files (woff2 is sufficient)

We should explore tools like https://github.com/tancredi/fantasticon for a better/more modern way to generate icon fonts and type defs

[ediblecode]

New monorepo tool

We use Lerna to manage and publish our different packages. This has worked really well for maintaining versions but it's always been a bit complicated. We never worked a way to integrate it properly into our CI pipeline because of time constraints. Lerna is now unsupported but a recent announcement (see lerna/lerna#3121) looks interesting for the future, and might involve nx.

[barkertron]

Spent a bit of time reading up on nx - came across this article by one of nx's founders:
https://blog.nrwl.io/why-you-should-switch-from-lerna-to-nx-463bcaf6821

Interestingly, towards the end he suggests that Lerna might still be better optimised for our kind of setup. It sounds like nx might not support our publishing workflow quite as well as Lerna out of the box, but plugins can still help to bridge the gap a bit (e.g. https://github.com/jscutlery/semver)

Probably one to spend some time faffing with to see how suitable it might be.

[ediblecode]

'Proper' scss modules

We namespace most of our SCSS functions/mixins/variables e.g. $nds-spacing-medium. This is great but since then SCSS have introduced 'proper' modules. We can probably make better of use of these to avoid having to namespace ourselves.

[ediblecode]

React Testing Library

If we're updating our build tooling to be TypeScript-first with a new monorepo setup then it probably makes sense to consider migrating from enzyme. We use RTL almost everywhere else so it would align the stack and there are a lot of clear reasons to use RTL over Enzyme.

[barkertron]

Would be a big fan of this - switching from RTL to Enzyme and back again is a headache

[barkertron]

Consolidated documentation

Storybook is extremely powerful and can do of a lot more than we're currently making use of. In particular, it's very good at mixing documentation with interactive code examples, helping to bridge the gap between the dev team and everyone else.

A really good example of this is Vibe, the design system of Monday.com.