🦋 Changeset is good to go

Latest commit: 0b468f2

We got this.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

Seems the @typescript-eslint/explicit-module-boundary-types rule is going to give a lot of trouble to react projects if they haven't been written that way from the beginning. It's only a warning as well which is mostly useless. Thoughts on disabling at the sku level? Or should we raise in eslint-config-seek?

I can see the benefit of explicitly declaring your return types.
Does the rule allow you to cast the function to a React.FunctionalComponent?

import React, { FunctionComponent } from 'react';

const App: FunctionalComponent<props> = () => {}

If so, and we believe it's a good pattern I'd suggest changing from warning to error in eslint-config-seek.
Alternatively I don't mind disabling the rule for sku/React projects as it's common pattern to assume a React component boundary is a React component.

Basically anything other than "leave it a warning". IMO warnings should only be used to temporarily downgrade an error in a project whilst in the process of migrating to the new pattern.

I find @typescript-eslint/explicit-module-boundary-types draconian even outside of React, and it's sneakily disabled for skuba projects. I think I snuck that one in behind @etaoins though, who is the senior principal advocate for it

I'm fine disabling @typescript-eslint/explicit-module-boundary-types for Sku. It's pretty full on.

I vote to remove it, seems a bit heavy handed.

If skuba and sku both disable then lets disable in eslint-config-seek?

PR updated to use eslint-config-seek@7.0.5

This PR is ready to go now. CI finally passing.