Fix icon compilation for developing on old/stale branches

[ggdouglas]

Fixes #0000

Checklist

• [N/A] Includes tests
• [N/A] Update documentation

Changes proposed in this pull request:

Fixes a build compilation error caused by generated icon components not being cleaned up.

In the current world, it is possible to:

1. Compile icons on the latest version of Blueprint (i.e. running yarn dev:docs on develop)
2. Switch to an older branch/PR
3. Compile icons again while developing on that branch
4. Encounter a type error due to stale icons referencing an outdated .ts manifest

More specifically, I've encountered this while checking out an older PR for local development (e.g. #6894) and the build erroring out on icons that were added later on (such as the data-search icon added in #6921). The generated icon at icons/src/generated/components/data-search.tsx still exists and references iconName="data-search", even though that icon name isn't exported by the generated name union (e.g. icons/src/generated/16px/blueprint-icons-16.ts)

This causes an error like the following:

src/generated/components/data-search.tsx:27:27 - error TS2769: No overload matches this call.
  Overload 1 of 2, '(props: SVGIconContainerProps<any>): ReactElement<any, string | JSXElementConstructor<any>> | null', gave the following error.
    Type '"data-search"' is not assignable to type 'BlueprintIcons_16Id'. Did you mean '"path-search"'?
  Overload 2 of 2, '(props: PropsWithChildren<SVGIconContainerProps<Element>>, context?: any): ReactElement<any, any> | null', gave the following error.
    Type '"data-search"' is not assignable to type 'BlueprintIcons_16Id'. Did you mean '"path-search"'?

27         <SVGIconContainer iconName="data-search" ref={ref}  {...props}>
                             ~~~~~~~~

  src/svgIconContainer.tsx:29:5

This change fixes this issue by cleaning up the icons/src/generated/components directory before compilation, which ensures the generated icon components are kept in sync with the name type manifest.

Reviewers should focus on:

Screenshot

[changelog-app]

Generate changelog in packages/icons/changelog/@unreleased

What do the change types mean?

• feature: A new feature of the service.
• improvement: An incremental improvement in the functionality or operation of the service.
• fix: Remedies the incorrect behaviour of a component of the service in a backwards-compatible way.
• break: Has the potential to break consumers of this service's API, inclusive of both Palantir services
  and external consumers of the service's API (e.g. customer-written software or integrations).
• deprecation: Advertises the intention to remove service functionality without any change to the
  operation of the service itself.
• manualTask: Requires the possibility of manual intervention (running a script, eyeballing configuration,
  performing database surgery, ...) at the time of upgrade for it to succeed.
• migration: A fully automatic upgrade migration task with no engineer input required.

Note: only one type should be chosen.

How are new versions calculated?

• ❗The break and manual task changelog types will result in a major release!
• 🐛 The fix changelog type will result in a minor release in most cases, and a patch release version for patch branches. This behaviour is configurable in autorelease.
• ✨ All others will result in a minor version release.

Type

• Feature
• Improvement
• Fix
• Break
• Deprecation
• Manual task
• Migration

Description

Fix icon compilation for developing on old/stale branches

Check the box to generate changelog(s)

• Generate changelog entry

[svc-palantir-github]

Ignore exceptions where generated directory does not yet exist (e.g. CI)

Build artifact links for this commit: documentation | landing | table | demo

This is an automated comment from the deploy-preview CircleCI job.