Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Uncaught TypeError: SvgIcon_default is undefined with vite in dev mode after @mui/icons-material@6.1.0+ #44180

Open
cmdcolin opened this issue Oct 22, 2024 · 4 comments
Assignees
Labels
bug 🐛 Something doesn't work package: icons Specific to @mui/icons

Comments

@cmdcolin
Copy link
Contributor

cmdcolin commented Oct 22, 2024

Steps to reproduce

Link to live example: (required) https://github.com/cmdcolin/mui-icons-material-error-repro

Steps:

  1. clone the repo
  2. run yarn
  3. run yarn dev
  4. observe dev tools error "Uncaught TypeError: SvgIcon_default is undefined"
  5. you can optionally checkout the commit HEAD~1 (at which i made a commit message "works") to show that it actually works in a case depending on order of the import of @mui/icons-material/Menu. you can additionally optionally apply a yarn resolution to get @mui/icons-material@6.0.2 to make it work.

Current behavior

The app fails to run in dev mode in vite due to a fatal error, and it appears to be related to the inclusion of our library and is sensitive to the order of import of the @mui/icons-material/Menu component.

Expected behavior

ideally we should be able to use our library, and not have sensitivity to order of imports.

Context

See the README in https://github.com/cmdcolin/mui-icons-material-error-repro for some technical context

The repro is a minimal "App" that only renders a single <Menu/> from @mui/icons-material/Menu, but it includes a function from our library also. I am using yarn v1 as a package manager and latest vite.

The error seems to appear only when our NPM package @jbrowse/react-linear-genome-view is used, and it is sensitive to the order of @mui/icons-material imports. our library uses @mui/material v6 including @mui/icons-material v6 as well. I found that @mui/icons-material@6.1.0+ introduced the above error. I saw that #31835 could be related (xref also #43624)

ideally, that PR should be a positive for helping most people but it seems to have caused issues with using our library in vite. I am not aware of anything particularly weird that @jbrowse/react-linear-genome-view does regarding imports, we always import from the full path e.g. '@mui/icons-material/Menu' not the barrel style {Menu} from '@mui/icons-material', but wasn't able to create a more minimal repro just yet. our library is not pure ESM.

if it seems like fixing this or hunting this down would be too complex, or making a proper fix would compromise other peoples setups more, then you can ignore this or wontfix it, i won't be upset :)

Your environment

npx @mui/envinfo

System:
OS: Linux 6.11 Ubuntu 24.10 24.10 (Oracular Oriole)
Binaries:
Node: 22.8.0 - /run/user/1001/fnm_multishells/17235_1729569485832/bin/node
npm: 10.8.2 - /run/user/1001/fnm_multishells/17235_1729569485832/bin/npm
pnpm: Not Found
Browsers:
Chrome: 127.0.6533.72
npmPackages:
@emotion/react: 11.13.3
@emotion/styled: 11.13.0
@mui/core-downloads-tracker: 6.1.4
@mui/icons-material: 6.1.4
@mui/material: 6.1.4
@mui/private-theming: 6.1.4
@mui/styled-engine: 6.1.4
@mui/system: 6.1.4
@mui/types: 7.2.18
@mui/utils: 6.1.4
@mui/x-charts-vendor: 7.20.0
@mui/x-data-grid: 7.21.0
@mui/x-internals: 7.21.0
@types/react: ^18.0.26 => 18.3.11
react: ^18.2.0 => 18.3.1
react-dom: ^18.2.0 => 18.3.1
typescript: ^5.1.6 => 5.6.3

I also used Firefox but chrome is the same (chrome makes the slightly different error message 'Cannot read properties of undefined (reading 'muiName')')

Search keywords: esbuild, vite, @mui/icons-material

@cmdcolin cmdcolin added the status: waiting for maintainer These issues haven't been looked at yet by a maintainer label Oct 22, 2024
@zannager zannager added the package: icons Specific to @mui/icons label Oct 22, 2024
@cmdcolin
Copy link
Contributor Author

random extra debugging:

this might be due to esbuild using our "commonjs" distribution. our commonjs build is created by using tsc with "target":"commonjs". we also have a "esm-style" distribution using the package.json "module" field (not type:"module" but the non-standard module field recognized by webpack and others), but this might be unused by esbuild.

the commonjs esm compatibility created by the typescript tsc compilation looks like this with the __importDefault helper

"use strict";
var __createBinding = (this && this.__createBinding) || (Object.create ? (function(o, m, k, k2) {
    if (k2 === undefined) k2 = k;
    var desc = Object.getOwnPropertyDescriptor(m, k);
    if (!desc || ("get" in desc ? !m.__esModule : desc.writable || desc.configurable)) {
      desc = { enumerable: true, get: function() { return m[k]; } };
    }
    Object.defineProperty(o, k2, desc);
}) : (function(o, m, k, k2) {
    if (k2 === undefined) k2 = k;
    o[k2] = m[k];
}));
var __setModuleDefault = (this && this.__setModuleDefault) || (Object.create ? (function(o, v) {
    Object.defineProperty(o, "default", { enumerable: true, value: v });
}) : function(o, v) {
    o["default"] = v;
});
var __importStar = (this && this.__importStar) || function (mod) {
    if (mod && mod.__esModule) return mod;
    var result = {};
    if (mod != null) for (var k in mod) if (k !== "default" && Object.prototype.hasOwnProperty.call(mod, k)) __createBinding(result, mod, k);
    __setModuleDefault(result, mod);
    return result;
};
var __importDefault = (this && this.__importDefault) || function (mod) {
    return (mod && mod.__esModule) ? mod : { "default": mod };
};
Object.defineProperty(exports, "__esModule", { value: true });
...
const Visibility_1 = __importDefault(require("@mui/icons-material/Visibility"));

if i change the package.json "main" to be our "module" field, then the code works, which leads me to believe that the main was being used by esbuild, and thus, the complicated esm compat layer listed above

all this should "ideally work" but i know esm and commonjs is often at odds

@DiegoAndai
Copy link
Member

Hey @cmdcolin, thanks for the report.

@Janpot, do you have an idea of what might be going on here? What I find very weird is that changing the import order changes the output:

// This order throws the error
import Menu from "@mui/icons-material/Menu";
import { createViewState } from "@jbrowse/react-linear-genome-view";

// This order doesn't throw
import { createViewState } from "@jbrowse/react-linear-genome-view";
import Menu from "@mui/icons-material/Menu";

@cmdcolin
Copy link
Contributor Author

yep the import order is odd. again if it's just me seeing this don't worry too much, the yarn resolution for the older @mui/icons-mateterial@6.0.2 works for me for now...

I am also following your work transitioning to package.json exports intently as I should transition to use export field in my own classes to move away from commonjs

@DiegoAndai
Copy link
Member

I'm tentatively linking it to #43264 as that should fix it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug 🐛 Something doesn't work package: icons Specific to @mui/icons
Projects
None yet
Development

No branches or pull requests

5 participants