[CLI] Unable to generate types with files that import .svg files

[jerelmiller]

Description

Hello 👋

I'm not quite sure whether to classify this as a bug or a feature request, so I've opened this up as a bug.

When running the CLI to generate theme types, the CLI will break if a file contains a non-JS import, such as an .svg file. For example, I have a Checkbox component that imports an .svg file to use as the checkbox icon. Doing so will break the CLI because it can't handle .svg imports.

Here is sample output from running the command for a component that imports an .svg file.

✘ [ERROR] No loader is configured for ".svg" files: ../../node_modules/my-icon-library/IconCheckmark.svg

    ../src/components/Checkbox.tsx:3:29:
      3 │ import IconCheckmark from 'my-icon-library/IconCheckmark.svg';
        ╵                           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


✖ UNHANDLED ERROR
✖ ERROR → Error
ℹ REASON → Build failed with 1 error:
../src/components/Checkbox.tsx:3:20: ERROR: No loader is configured for ".svg" files: ../../node_modules/my-icon-library/IconCheckmark.svg

---

I see the CLI uses esbuild to parse the component files. This command appears to use reasonable configuration to handle this task, but I see there are no configured loaders. This makes sense from the perspective of the tool given that its task is not to bundle production code, but rather extract information from the code.

Would it be possible for the CLI to either provide a sensible default set of loaders for common file types (png, jpg, svg, etc.) or provide a way to specify a set of loaders so that the CLI task can work with components that import non-JS/TS files?

I've been able to patch this locally (via patch-package) by adding a loader property to that build command. The empty loader seems to work well here since I don't really need to care about the svg contents for type generation. My patched, working config looks like this:

await build({
  // ... existing stuff,
  loader: {
    '.svg': 'empty'
  }
});

Appreciate all the work you've put into the library!

(NOTE: I've omitted a reproduction in favor of links to source code and a resolution for this issue. I'd be happy to provide a minimal reproduction if the above isn't sufficient enough).

Link to Reproduction

See description above for proposed resolution

Steps to reproduce

No response

Chakra UI Version

2.8.2

Browser

No response

Operating System

• macOS
• Windows
• Linux

Additional Information

No response

[segunadebayo]

Thanks for digging into the issue and suggesting a fix.

I don't recommend importing the svg file in the theme file. Kindly refactor it to separate the theme from the custom component code.

You can also keep the patch for now. In the v3 version, we'll consider it.

[jerelmiller]

Hey @segunadebayo appreciate the response!

We don't have svg imports directly in our theme file. Our structure is roughly equivalent to the following:

// ChakraThemeProvider.tsx
import {
  AlertStyles,
  CheckboxStyles,
  // ...etc
} from 'our-ui-library';

const theme = extendTheme({
  components: {
    Alert: AlertStyles,
    Checkbox: CheckboxStyles,
    // ...etc
  }
})

where our-ui-library is an (internal) npm package with an index file that looks like this:

// index.ts
export { Checkbox } from './src/Checkbox';
export { CheckboxStyles } from './src/Checkbox.style';

In this case Checkbox.tsx has an .svg import that is used with the file. Our CLI is set to generate types from the ChakraThemeProvider.tsx file, but my guess is that esbuild is following the imports from the entry file and choking because it ends up trying to build the Checkbox.tsx file with the .svg imports.

Unfortunately its a bit difficult to change our file structure due to our-ui-library being a separate npm package. If I'm understanding what you're saying, we'd need to rethink our file/bundling structure in this package to ensure esbuild won't end up trying to build files in our internal package that have non-JS imports correct?