@haszari do you have a PR I can look at? The problem should be fixable by making the classNames prop optional on the type. Instead of a type like

interface WizardTaskItemProps {
    // some other props…
    classNames: string;
}

Make the classNames optional:

interface WizardTaskItemProps {
    // some other props…
    classNames?: string; // Note the `?` to make the prop optional.
}

If the components are JS components it should be possible to define the types using JSDoc comments in the component files themselves:

/**
 * @param {string} [classNames] The classes assigned to the task item.
 */
export const WizardTaskItem = ( { /* other props */, classNames } ) => {
    // …
};

This will all mean undefined (i.e. not providing a prop) is possible. If we explicitly want null to be an option that must be specified:

interface WizardTaskItemProps {
    // some other props…
    classNames: string | null; // Must provide either a string or null, not providing the prop is not an option.
}

interface WizardTaskItemProps {
    // some other props…
    classNames?: string | null; // string, null, or undefined allowed, not providing the prop **is an option**.
}

/**
 * @param {string|null} classNames Must provide either a string or null, not providing the prop is not an option.
 */
export const WizardTaskItem = ( { /* other props */, classNames } ) => {
    // …
};

/**
 * @param {string|null} [classNames] string, null, or undefined allowed, not providing the prop **is an option**.
 */
export const WizardTaskItem = ( { /* other props */, classNames } ) => {
    // …
};

The JSDoc syntax supported by TS is documented here.

do you have a PR I can look at?

• Add support for Japan to the tax details modal #8974

That's the PR where I encountered it, but I haven't deleted the classNames = {null} on that PR branch. I can spin up a PR demonstrating the bug, basically delete classNames={null} in a couple of places!

I think this can be fixed by adding a default (e.g. classNames = null) to the relevant JS components (WizardTaskItem, CollapsibleBody).
The problem should be fixable by making the classNames prop optional on the type.

For sure, that's what I was assuming. Adding a default param (to the JavaScript definition) fixed the bug, and seems sensible to me. @reykjalin what do you think of that fix – is it "hacky" in some way?

It seems an optional bonus to define these components as TypeScript types, I'd default to leaving them implicit, but I'm curious to hear rationale for why making the types explicit would be better.

Adding a default param (to the JavaScript definition) fixed the bug, and seems sensible to me

Ah yes, that's even cleaner! I just didn't realize that was an option since it seemed based on the issue description that it should be possible to pass null to indicate some form of "nothingness", as opposed to using a default value.

So long as using a default value matches the previous version of the API I see no problem with doing that 👍

To elaborate a bit, here's an example where it wouldn't match:

// Previous. Silly example
export const WeirdComponent = ( { classNames } ) => (
  <div className={ classNames }>
  </div>
);

// New. Still silly example.
export const WeirdComponent = ( { classNames = 'default' } ) => (
  <div className={ classNames }>
  </div>
);

The difference between the 2 is that the previous version allows null and undefined whereas the new one does not. That would be a change I wouldn't recommend. But then you can just make the default value undefined or null, in which case the change is fine.

All of this to say: make sure the default value matches the previous implementation and you should be fine! 🙂