.d.ts errors in the build package after lazy loading got introduced

I’m working on the React package for a design system and noticed that some of the components using have all the .svg in the built package output. Because of that my package size was 4mb.

I introduced lazy loading of the icons in the Icon component. That was the only change. Thanks to that now the package is no 1mb.

Surprisingly, since then, when I bump to the new version in my consuming app I get tons of errors complaining about .d.ts files.

ERROR in
./node_modules/@company/package/dist/components/radio/icons/index.d.ts
1:0-54 Module not found: Error: Can’t resolve ‘./radio-off.svg’ in
‘PATH_TO_PACKAGE’ Did you miss the leading dot in
‘resolve.extensions’? Did you mean
‘[“.“,”.wasm”,”.mjs”,”.js”,”.jsx”,”.json”,”.ts”,”.tsx”]’ instead of
‘[““,”.wasm”,”.mjs”,”.js”,”.jsx”,”.json”,”.ts”,”.tsx”]’?
ERROR in
./node_modules/@company/mypackagename/dist/types/data-activation-api.d.ts
5:7 Module parse failed: Unexpected token (5:7) You may need an
appropriate loader to handle this file type, currently no loaders are
configured to process this file. See
https://webpack.js.org/concepts#loaders | * Do not make direct
changes to the file. | */

export interface paths { | ‘/organization/{orgId}/data-set/{dataSetId}/traversal/{traversalId}/status’:
{ | parameters: {

ERROR in
./node_modules/@company/mypackagename/dist/types/data-catalog-api.d.ts
5:7 Module parse failed: Unexpected token (5:7) You may need an
appropriate loader to handle this file type, currently no loaders are
configured to process this file. See
https://webpack.js.org/concepts#loaders | * Do not make direct
changes to the file. | */

export interface paths { | ‘/organization/{organizationId}/entity/{entityId}/data-fields/{fieldId}’:
{ | parameters: {

ERROR in
./node_modules/@company/mypackagename/dist/types/data-integration-api.d.ts
5:7 Module parse failed: Unexpected token (5:7) You may need an
appropriate loader to handle this file type, currently no loaders are
configured to process this file. See
https://webpack.js.org/concepts#loaders | * Do not make direct
changes to the file. | */

export interface paths { | ‘/api/v1/integrations/datasources’: { | parameters: {

ERROR in
./node_modules/@company/mypackagename/dist/types/theme-interfaces.d.ts
2:12 Module parse failed: Unexpected token (2:12) You may need an
appropriate loader to handle this file type, currently no loaders are
configured to process this file. See
https://webpack.js.org/concepts#loaders | import
‘@mui/material/styles’;

import type { spacingScale, unitsScale } from ‘theme’; | declare module ‘@mui/material/styles’ { | interface TypeText {

Again, the only changes that happened was the lazy loading from the screenshot changelog in the Icon.tsx.

My tsconfig

{
  "compilerOptions": {
    "baseUrl": ".",
    "target": "es6",
    "lib": ["dom", "dom.iterable", "esnext"],
    "allowJs": true,
    "skipLibCheck": true,
    "strict": true,
    "declaration": true,
    "outDir": "./dist",
    "rootDir": ".",
    "declarationDir": "./dist",
    "forceConsistentCasingInFileNames": true,
    "esModuleInterop": true,
    "module": "esnext",
    "moduleResolution": "node",
    "resolveJsonModule": true,
    "isolatedModules": true,
    "sourceMap": true,
    "declarationMap": true,
    "jsx": "react-jsx",
    "incremental": false,
    "paths": {
      "components/*": ["components/*"],
      "images/*": ["images/*"],
      "theme/*": ["theme/*"],
      "types/*": ["types/*"],
      "utils/*": ["utils/*"],
    },
    "plugins": []
  },
  "include": ["**/*.ts", "**/*.tsx"],
  "exclude": ["node_modules", "dist"]
}

And webpack config:

const path = require('path');
const glob = require('glob');
const TerserPlugin = require('terser-webpack-plugin');
const { CleanWebpackPlugin } = require('clean-webpack-plugin');
const { getEntries } = require('./getEntries');

module.exports = {
  entry: getEntries(),
  mode: 'production',
  output: {
    path: path.resolve(__dirname, 'dist'),
    filename: (pathData) => {
      const name = pathData.chunk.name;
      if (name === 'theme') {
        return 'theme/index.js';
      }

      return `${name}.js`;
    },
    libraryTarget: 'module',
    globalObject: 'this',
  },
  module: {
    rules: [
      {
        test: /.(ts|tsx)$/,
        exclude: /node_modules/,
        use: {
          loader: 'babel-loader',
        },
      },
      {
        test: /.css$/,
        use: ['style-loader', 'css-loader'],
      },
      {
        test: /.svg$/,
        use: [
          {
            loader: '@svgr/webpack',
            options: {
              typescript: true,
              ref: true,
              svgProps: {
                role: 'img',
                width: '24',
                height: '24',
                fill: 'currentColor',
              },
            },
          },
        ],
      },
    ],
  },
  resolve: {
    extensions: ['.ts', '.tsx', '.js', '.jsx'],
    alias: {
      components: path.resolve(__dirname, 'components'),
      theme: path.resolve(__dirname, 'theme'),
      images: path.resolve(__dirname, 'images'),
      types: path.resolve(__dirname, 'types'),
    },
  },
  externals: {
    react: 'react',
    'react-dom': 'react-dom',
    '@mui/material': '@mui/material',
    '@mui/material/styles': '@mui/material/styles',
    '@emotion/react': '@emotion/react',
    '@emotion/styled': '@emotion/styled',
    next: 'next',
  },
  optimization: {
    minimizer: [
      new TerserPlugin(),
    ],
  },
  plugins: [new CleanWebpackPlugin()],
  experiments: {
    outputModule: true,
  },
};

I’m completely lost why such change could introduce so many (300+ errors). What is more – my consuming app works, it’s just about the CI errors when I run it, but when I open it in the browser all is good. The errors are from the terminal.

I know I could fix in the consuming app by doing:

{
  test: /.d.ts$/,
  loader: 'ignore-loader',
},

But I don’t want to force customers of the package to do such workarounds and special configs.