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

Storybook w/ Typescript takes ~2 minutes to load a story. #10784

Closed
MarkLyck opened this issue May 14, 2020 · 47 comments
Closed

Storybook w/ Typescript takes ~2 minutes to load a story. #10784

MarkLyck opened this issue May 14, 2020 · 47 comments

Comments

@MarkLyck
Copy link
Contributor

MarkLyck commented May 14, 2020

Describe the bug
A clear and concise description of what the bug is.

The initial load of storybook takes about 2 minutes to load when using Typescript.
When not using Typescript it takes a few seconds.

Code changes also takes a very long time to reflect in the story.

My guess is that it doesn't exclude node_modules correctly.

To Reproduce
Steps to reproduce the behavior:

  1. Set up storybook with typescript
  2. run yarn start-storybook -s ./public -c .storybook -p 9001 --ci
  3. Takes about 2 minutes before you can see a story, and code changes takes a long time to reflect.

Expected behavior
It should load about as fast as it does with pure JS.
It should not need to compile node_modules

Screenshots
Screen Shot 2020-05-14 at 2 23 44 PM

Code snippets
If applicable, add code samples to help explain your problem.

webpack.config.js

const TsconfigPathsPlugin = require('tsconfig-paths-webpack-plugin')

module.exports = ({ config }) => {
  config.module.rules.push({
    test: /\.(ts|tsx)$/,
    exclude: /node_modules/,
    use: [
      {
        loader: require.resolve('awesome-typescript-loader'),
        options: {
          exclude: /node_modules/,
          presets: [['react-app', { flow: false, typescript: true }]],
          configFileName: './.storybook/tsconfig.json',
        },
      },
      {
        loader: require.resolve('react-docgen-typescript-loader'),
        options: {},
      },
    ],
  })

  config.resolve.extensions.push('.ts', '.tsx')
  config.resolve.plugins = [new TsconfigPathsPlugin()]
  return config
}

tsconfig.json

{
  "compilerOptions": {
    "outDir": "build/lib",
    "module": "commonjs",
    "strictNullChecks": true,
    "skipLibCheck": true,
    "moduleResolution": "node",
    "esModuleInterop": true,
    "experimentalDecorators": true,
    "jsx": "react",
    "noUnusedParameters": true,
    "noUnusedLocals": true,
    "noImplicitAny": true,
    "noImplicitThis": true,
    "declaration": true,
    "allowSyntheticDefaultImports": true,
    "emitDecoratorMetadata": true,
    "target": "es5",
    "lib": ["es5", "es6", "es7", "es2017", "dom"],
    "sourceMap": true,
    "types": ["react", "node"],
    "baseUrl": "../",
    "paths": {
      "~*": ["./src*"],
      "components": ["./src/components/*"],
      "ui-components": ["./src/ui-components/*"],
      "pages": ["./src/pages/*"],
      "common": ["src/common/*"],
      "mocks": ["./mocks/*"],
      "lib": ["./lib/*"]
    },
  },
  "include": ["src/**/*", "../src/typings.d.ts"],
  "exclude": [
    "node_modules",
    "build",
    "dist",
    "scripts",
    "acceptance-tests",
    "webpack",
    "jest",
    "src/setupTests.ts",
    "**/*/*.test.ts",
    "examples"
  ]
}

As far as I can tell from any docs or similar problems, this should exclude node_modules correctly.

System:
System:
OS: macOS 10.15.4
CPU: (8) x64 Intel(R) Core(TM) i7-6920HQ CPU @ 2.90GHz
Binaries:
Node: 12.12.0 - /usr/local/bin/node
Yarn: 1.17.3 - /usr/local/bin/yarn
npm: 6.14.4 - /usr/local/bin/npm
Browsers:
Chrome: 81.0.4044.138
Firefox: 70.0.1
Safari: 13.1
npmPackages:
@storybook/addon-a11y: ^5.3.18 => 5.3.18
@storybook/addon-actions: ^5.3.18 => 5.3.18
@storybook/addon-info: ^5.3.18 => 5.3.18
@storybook/addon-knobs: ^5.3.18 => 5.3.18
@storybook/addon-links: ^5.3.18 => 5.3.18
@storybook/addon-storysource: ^5.3.18 => 5.3.18
@storybook/addon-viewport: ^5.3.18 => 5.3.18
@storybook/react: ^5.3.18 => 5.3.18

@shilman
Copy link
Member

shilman commented May 15, 2020

@MarkLyck
Copy link
Contributor Author

@shilman

Thanks for the quick response. I tried with just the default preset and nothing else, and it's a little better.

It now takes ~1.5 minutes instead. of 2-3. minutes.

But looking at the logs it still spends the vast majority of the time compiling node_modules I don't use in my stories. The longest time is spent loading amcharts and ALL @ant-design/icons

Is there any way to exclude libraries I don't need to load in my storybook?

Screen Shot 2020-05-15 at 11 36 08 AM

@shilman
Copy link
Member

shilman commented May 15, 2020

It shouldn't be processing node_modules at all... 🤔

@MarkLyck
Copy link
Contributor Author

MarkLyck commented May 15, 2020

@shilman Glad to hear that it's not supposed to do that!

From the logs it looks like it's the type checking. Before it starts building node_modules it logs "Starting type checking service..."

After building all the node_modules it logs "No type errors found"

So looks like it's typescript building all this stuff? But my tsconfig (pasted above) have node_modules excluded as well 🤷‍♂️

@MarkLyck
Copy link
Contributor Author

MarkLyck commented May 15, 2020

Even if I remove the .storybook/tsconfig.json it still builds my node_modules during type checking.

Although it might just be picking up the project level tsconfig.json instead

@shilman
Copy link
Member

shilman commented May 15, 2020

There is no .storybook/tsconfig.json AFAIK. We're upgrading Storybook's typescript support in the next few days, and I'll be sure to bring this into the discussion cc @mrmckeb

@MarkLyck
Copy link
Contributor Author

@shilman

It's about half the loading time with the preset, so I'll take that as a win for now, and check back when the typescript support is updated to see if there's any updates :)

Thanks for the help!

@shilman
Copy link
Member

shilman commented May 21, 2020

We've just released zero-config typescript support in 6.0-beta. Please upgrade and test it!

Thanks for your help and support getting this stable for release!

@MarkLyck
Copy link
Contributor Author

@shilman thanks for the update!

I updated to 6.0.0-beta.12 (& updated my configs to the new main.js & preview.js files).

I removed the typescript-preset mentioned earlier in this thread as there was an error it already existed.

However, it's still building all of my node_modules every time, and it still takes 1-2 minutes to load. (actually seems a bit slower now)

Screen Shot 2020-05-21 at 9 09 34 AM

@shilman
Copy link
Member

shilman commented May 21, 2020

@MarkLyck the speed difference is probably due to react-docgen (fast-ish and default in the preset) vs react-docgen-loader (slow-ish and default in the new setup)

i don't understand why it's so slow. do you have a repro repo you can share?

@MarkLyck
Copy link
Contributor Author

MarkLyck commented May 21, 2020

@shilman it's a private repo, but I'll invite you as a temporary collab so you can see it.

Or if needed I can try to create a dummy repo to reproduce, but not sure how long that will take.

The branch for storybook 6 is storybook6
Master branch has the @preset-typescript with [email protected]

https://github.com/MarkLyck/weeklystocktip/tree/storybook6

only setup needed is yarn install
and then yarn storybook to start storybook.

There is a custom webpack in there to load .less files for antd theming. But it takes just a long to load without it.

I can make a branch without this if that helps.

@shilman
Copy link
Member

shilman commented May 21, 2020

Thanks @MarkLyck i've cloned the repo and will delete it when I'm done with this. Feel free to remove me as a collaborator.

I played with the settings in .storybook/main.js like this:

  typescript: {
    reactDocgen: 'react-docgen',
  },

Values on my machine:

  • false: 28s
  • 'react-docgen': 29s
  • 'react-docgen-typescript': 59s

For now, I think switching the default is about as good as it's going to get. We'll do a performance release later this year where we should be able to get this number down a lot. Next.js will be releasing their own preset soon, and perhaps they can also provide some Next.js-specific optimizations.

@MarkLyck
Copy link
Contributor Author

MarkLyck commented May 21, 2020

@shilman Thank you!

Can confirm with react-docgen I'm also seeing 29s for manager, 1.15min for preview 😄

much better build times. But I'm guessing with this method I won't get the TypeScript types for automated documentation? something I was hoping to implement when @6 is stable.

So it is next.js that's causing the slow storybook build times?

P.S. looking forward to the performance release later this year! You guys are doing an awesome job thank you so much for working on this tool!

EDIT also made it slightly faster by removing all icons from @ant-design/icons and only just FontAwesome icons in my project. (something I wanted to do anyway). Now it's down to 20-25 seconds for the manager and 40-45 seconds for the preview.

@stale
Copy link

stale bot commented Jun 12, 2020

Hi everyone! Seems like there hasn't been much going on in this issue lately. If there are still questions, comments, or bugs, please feel free to continue the discussion. Unfortunately, we don't have time to get to every issue. We are always open to contributions so please send us a pull request if you would like to help. Inactive issues will be closed after 30 days. Thanks!

@stale stale bot added the inactive label Jun 12, 2020
@shilman
Copy link
Member

shilman commented Jun 12, 2020

If you switched from react-docgen-typescript to react-docgen after reading this issue, please consider switching back. react-docgen-typescript support is better and we just got a big performance improvement here: #11106

Here are the numbers I'm seeing for official-storybook on my dev machine:

  • react-docgen: 17 s for manager and 21 s for preview
  • react-docgen-typescript (before): 36 s for manager and 46 s for preview
  • react-docgen-typescript (after): 15 s for manager and 31 s for preview

@stale stale bot removed the inactive label Jun 12, 2020
@stale
Copy link

stale bot commented Jul 3, 2020

Hi everyone! Seems like there hasn't been much going on in this issue lately. If there are still questions, comments, or bugs, please feel free to continue the discussion. Unfortunately, we don't have time to get to every issue. We are always open to contributions so please send us a pull request if you would like to help. Inactive issues will be closed after 30 days. Thanks!

@stale stale bot added the inactive label Jul 3, 2020
@lacolaco
Copy link

lacolaco commented Jul 21, 2020

I'm in the same situation with @storybook/angular 6.0.0-rc.12. It takes 2-3 minutes for responding the first HTML. build-storybook is not slow.

@stale stale bot removed the inactive label Jul 21, 2020
@shilman
Copy link
Member

shilman commented Jul 21, 2020

@lacolaco i suspect that's due to a perf bug in 6.0 and not typescript related #11618

@lacolaco
Copy link

@shilman Thanks. I'll subscribe that issue.

@stale
Copy link

stale bot commented Aug 16, 2020

Hi everyone! Seems like there hasn't been much going on in this issue lately. If there are still questions, comments, or bugs, please feel free to continue the discussion. Unfortunately, we don't have time to get to every issue. We are always open to contributions so please send us a pull request if you would like to help. Inactive issues will be closed after 30 days. Thanks!

@stale stale bot added the inactive label Aug 16, 2020
@RushikeshJoshi4
Copy link

@MarkLyck Hey. I'm stuck on a similar issue. Did you find any solution? I got rid of react-docgen and withInfo decorator but it still, for some reason, builds node_modules.

@Obiwarn
Copy link

Obiwarn commented Nov 3, 2020

Same problem here: It builds node modules for ages.

@shilman
Copy link
Member

shilman commented Nov 3, 2020

@Obiwarn sounds like a configuration problem. do you have a repro you can share?

@simonepizzamiglio
Copy link

@shilman I also have the same problem, storybook builds node modules folder, here's my main.js file:

const path = require('path');

module.exports = {
  stories: ['../src/**/*.stories.@(js|tsx|md|mdx)', '../src/**/stories.@(js|tsx|md|mdx)'],
  test: /\.(ts|tsx)$/,
  typescript: {
    check: true,
    reactDocgen: 'react-docgen-typescript',
  },
  addons: [
    '@storybook/addon-actions',
    '@storybook/addon-knobs',
    '@storybook/addon-links',
    '@storybook/addon-viewport',
    '@storybook/addon-docs',
    '@storybook/preset-create-react-app',
  ],
  exclude: [/node_modules/, '/src/**/*/*.test.ts', '/src/**/*/*.test.tsx'],
  webpackFinal: async config => {
    config.resolve.modules = [path.resolve(__dirname, '../src/'), 'node_modules'];

    return config;
  },
};

@shilman
Copy link
Member

shilman commented Nov 4, 2020

Cc @mrmckeb

@Obiwarn
Copy link

Obiwarn commented Nov 4, 2020

@shilman
This happens to me with a blank project.
I create a new project with CRA and run sb init:

npx create-react-app my-app
cd my-app
npx sb init

On npm run storyboard it builds many node_modules.

Regular build is 19s and debug build in Webstorm over 3 min!

│ Storybook 6.0.28 started │ │ 19 s for manager and 18 s for preview │

Debug:

│ Storybook 6.0.28 started │ │ 3.63 min for manager and 3.67 min for preview │

@shilman
Copy link
Member

shilman commented Nov 4, 2020

@Obiwarn

Debug means running it in the webstorm debugger?

The first numbers look "normal". We're optimizing away the manager build entirely in 6.1-beta (available with npx sb@next init for new projects, npx sb@next upgrade --prerelease for an upgrade), and incrementally optimizing the preview over the next few releases.

The second set of numbers look crazy. I guess I'd recommend not running it in debug mode?

@Obiwarn
Copy link

Obiwarn commented Nov 4, 2020

@shilman

Debug mode is to go through the code step by step with the debugger. It is a blessing. We use it a lot.

So the compilation of the node_modules is intentional?

@simonepizzamiglio
Copy link

@shilman
This happens to me with a blank project.
I create a new project with CRA and run sb init:

npx create-react-app my-app
cd my-app
npx sb init

On npm run storyboard it builds many node_modules.

Regular build is 19s and debug build in Webstorm over 3 min!

│ Storybook 6.0.28 started │ │ 19 s for manager and 18 s for preview │

Debug:

│ Storybook 6.0.28 started │ │ 3.63 min for manager and 3.67 min for preview │

Same here, running

npx create-react-app my-app
cd my-app
npx sb init
npm run storybook

takes 20 s for manager and 21 s for preview and builds the node_modules folder.

I mean it's a reasonable time, what looks weird to me is that the build goes through the node_modules folder.

@pachuka
Copy link

pachuka commented Nov 23, 2020

Another thing to check (a co-worker ran into this issue) is try running storybook in "quiet" mode, this reduces the amount of text it prints to the terminal. Co-worker had multi-minute builds, and after using quiet mode it matched my build times of < 1min.

npx start-storybook --quiet

@stale
Copy link

stale bot commented Dec 25, 2020

Hi everyone! Seems like there hasn't been much going on in this issue lately. If there are still questions, comments, or bugs, please feel free to continue the discussion. Unfortunately, we don't have time to get to every issue. We are always open to contributions so please send us a pull request if you would like to help. Inactive issues will be closed after 30 days. Thanks!

@stale stale bot added the inactive label Dec 25, 2020
@tonypee
Copy link

tonypee commented Jan 20, 2021

Im getting this issue too. Surely if an empty project made with CRA can expose this (as per @Obiwarn 's comment) - it should be repro'able? we are just switching config/setup for sb and experiencing it. I actually get a whole lot of ts errors in the node_modules:
image

hmm

@stale stale bot removed the inactive label Jan 20, 2021
@btmnk
Copy link

btmnk commented Feb 12, 2021

Another thing to check (a co-worker ran into this issue) is try running storybook in "quiet" mode, this reduces the amount of text it prints to the terminal. Co-worker had multi-minute builds, and after using quiet mode it matched my build times of < 1min.

npx start-storybook --quiet

I can confirm this (Typescript Monorepo Project for UI Components).
I don't really mind the longer build time but the fast refresh build times where way too long (~10 seconds). After starting storybook with the --quiet flag not only did the build time go down significantly but also the fast refresh also worked as expected with less than 1-2 seconds of time between changing the code and seeing the result in storybook.

I'm on macOS Mojave - maybe that's somehow helping.

@InsOpDe
Copy link

InsOpDe commented Mar 11, 2021

I mean it's a reasonable time, what looks weird to me is that the build goes through the node_modules folder.

In the end it boils down to the webpack configuration being used. If node_modules is excluded in every webpack-rule node_modules should be excluded from being iterated as it is at the moment. if the modules are in fact not excluded, its a webpack issue.

is it as trivial as I described?

@SyedUmerHasan
Copy link

I am also confirming this issue exist, node_modules needs to be excluded from the build. Issue reproducible with Lerna monorepo.

@orange727
Copy link

I am also confirming this issue exist, node_modules needs to be excluded from the build. Issue reproducible with Lerna monorepo.

I have the same problem。lerna monorepo, build time cost 3mins。I added 'exclude' in webpack.config.js and tsconfig.json,but not work。I dont' know how to locate the problem。

i have my packages like this:

  • packages
    • a component
    • b component
    • all

I run npx start-storybook in directory 'a', cost 1min。when i run that command at directory -- 'all', cost 3 mins。

@karol-f
Copy link

karol-f commented Jun 25, 2021

@orange727 Add this to storybook config e.g. in main.js:

module.exports = {
        ....
	typescript: {
		check: false,
		reactDocgen: false,
	},
        ....
};

@adamwdennis
Copy link

Can confirm that by turning off reactDocgen in main.js, per @karol-f's comment (thanks!), it cut my storybook build time by quite a bit. I don't need docgen right now while I'm in early development, so this is perfect!

Before:

Storybook 6.4.7 for React started │ 32 s for manager and 43 s for preview

After:

Storybook 6.4.7 for React started │ 16 s for preview

@stale
Copy link

stale bot commented Jan 9, 2022

Hi everyone! Seems like there hasn't been much going on in this issue lately. If there are still questions, comments, or bugs, please feel free to continue the discussion. Unfortunately, we don't have time to get to every issue. We are always open to contributions so please send us a pull request if you would like to help. Inactive issues will be closed after 30 days. Thanks!

@stale stale bot added the inactive label Jan 9, 2022
@matheusfcorocher
Copy link

I was facing the same problem, but my OS is Windows. I change my project from Windows filesystem to Linux filesystem(using WSL2) and it improve a lot the time to load a story and also hot reload.

@stale stale bot removed the inactive label Jul 15, 2022
@shilman shilman added this to the 8.1 annotations server milestone Jun 8, 2023
@shilman
Copy link
Member

shilman commented Aug 23, 2023

Can you try out the following canary in your project and let me know whether it resolves any of your issues (or generates new ones)? We're looking to switch the default docgen from react-docgen-typescript to react-docgen, which is much faster and may also fix some long-standing bugs. Many thanks!

Note that the change is currently only for Vite projects. Instructions in the "how to test" section: 👉 #23825

@rkuykendall
Copy link

@shilman I am having the same issue ( 2 minute startup time ) which I can confirm goes away if I set reactDocgen: false. I switched all libraries to 0.0.0-pr-23825-sha-7875282b and changed to reactDocgen: 'react-docgen' but that generated the following errors:

Browser:

Failed to fetch dynamically imported module: http://localhost:3001/.storybook/preview.tsx
TypeError: Failed to fetch dynamically imported module: http://localhost:3001/.storybook/preview.tsx

Console

12:58:00 PM [vite] Internal server error: Attempted to resolveName for an unsupported path. resolveName does not accept ObjectMethod".
  Plugin: storybook:react-docgen-plugin
  File: /Users/rkuykendall/projects/front-end/common/dist/common.es.js
      at resolveName (/Users/rkuykendall/projects/front-end/node_modules/react-docgen/dist/utils/getMemberExpressionValuePath.js:72:9)
      at getMemberExpressionValuePath (/Users/rkuykendall/projects/front-end/node_modules/react-docgen/dist/utils/getMemberExpressionValuePath.js:91:21)
      at getMemberValuePath (/Users/rkuykendall/projects/front-end/node_modules/react-docgen/dist/utils/getMemberValuePath.js:95:62)
      at resolveToValue (/Users/rkuykendall/projects/front-end/node_modules/react-docgen/dist/utils/resolveToValue.js:139:66)
      at Object.toArray (/Users/rkuykendall/projects/front-end/node_modules/react-docgen/dist/utils/expressionTo.js:49:64)
      at isExportsOrModuleAssignment (/Users/rkuykendall/projects/front-end/node_modules/react-docgen/dist/utils/isExportsOrModuleAssignment.js:40:32)
      at Object.assignmentExpressionVisitor (/Users/rkuykendall/projects/front-end/node_modules/react-docgen/dist/resolver/FindExportedDefinitionsResolver.js:56:55)
      at NodePath._call (/Users/rkuykendall/projects/front-end/node_modules/@babel/traverse/lib/path/context.js:46:20)
      at NodePath.call (/Users/rkuykendall/projects/front-end/node_modules/@babel/traverse/lib/path/context.js:36:17)
      at NodePath.visit (/Users/rkuykendall/projects/front-end/node_modules/@babel/traverse/lib/path/context.js:82:31)
      at TraversalContext.visitQueue (/Users/rkuykendall/projects/front-end/node_modules/@babel/traverse/lib/context.js:86:16)
      at TraversalContext.visitSingle (/Users/rkuykendall/projects/front-end/node_modules/@babel/traverse/lib/context.js:65:19)
      at TraversalContext.visit (/Users/rkuykendall/projects/front-end/node_modules/@babel/traverse/lib/context.js:109:19)
      at traverseNode (/Users/rkuykendall/projects/front-end/node_modules/@babel/traverse/lib/traverse-node.js:22:17)
      at NodePath.visit (/Users/rkuykendall/projects/front-end/node_modules/@babel/traverse/lib/path/context.js:88:52)
      at TraversalContext.visitQueue (/Users/rkuykendall/projects/front-end/node_modules/@babel/traverse/lib/context.js:86:16)
      at TraversalContext.visitMultiple (/Users/rkuykendall/projects/front-end/node_modules/@babel/traverse/lib/context.js:61:17)
      at TraversalContext.visit (/Users/rkuykendall/projects/front-end/node_modules/@babel/traverse/lib/context.js:107:19)
      at traverseNode (/Users/rkuykendall/projects/front-end/node_modules/@babel/traverse/lib/traverse-node.js:22:17)
      at NodePath.visit (/Users/rkuykendall/projects/front-end/node_modules/@babel/traverse/lib/path/context.js:88:52)
      at TraversalContext.visitQueue (/Users/rkuykendall/projects/front-end/node_modules/@babel/traverse/lib/context.js:86:16)
      at TraversalContext.visitSingle (/Users/rkuykendall/projects/front-end/node_modules/@babel/traverse/lib/context.js:65:19)
      at TraversalContext.visit (/Users/rkuykendall/projects/front-end/node_modules/@babel/traverse/lib/context.js:109:19)
      at traverseNode (/Users/rkuykendall/projects/front-end/node_modules/@babel/traverse/lib/traverse-node.js:22:17)
      at NodePath.visit (/Users/rkuykendall/projects/front-end/node_modules/@babel/traverse/lib/path/context.js:88:52)
      at TraversalContext.visitQueue (/Users/rkuykendall/projects/front-end/node_modules/@babel/traverse/lib/context.js:86:16)
      at TraversalContext.visitMultiple (/Users/rkuykendall/projects/front-end/node_modules/@babel/traverse/lib/context.js:61:17)
      at TraversalContext.visit (/Users/rkuykendall/projects/front-end/node_modules/@babel/traverse/lib/context.js:107:19)
      at traverseNode (/Users/rkuykendall/projects/front-end/node_modules/@babel/traverse/lib/traverse-node.js:22:17)
      at NodePath.visit (/Users/rkuykendall/projects/front-end/node_modules/@babel/traverse/lib/path/context.js:88:52)
      at TraversalContext.visitQueue (/Users/rkuykendall/projects/front-end/node_modules/@babel/traverse/lib/context.js:86:16)
      at TraversalContext.visitSingle (/Users/rkuykendall/projects/front-end/node_modules/@babel/traverse/lib/context.js:65:19)
      at TraversalContext.visit (/Users/rkuykendall/projects/front-end/node_modules/@babel/traverse/lib/context.js:109:19)
      at traverseNode (/Users/rkuykendall/projects/front-end/node_modules/@babel/traverse/lib/traverse-node.js:22:17)
      at NodePath.visit (/Users/rkuykendall/projects/front-end/node_modules/@babel/traverse/lib/path/context.js:88:52)
      at TraversalContext.visitQueue (/Users/rkuykendall/projects/front-end/node_modules/@babel/traverse/lib/context.js:86:16)
      at TraversalContext.visitMultiple (/Users/rkuykendall/projects/front-end/node_modules/@babel/traverse/lib/context.js:61:17)
      at TraversalContext.visit (/Users/rkuykendall/projects/front-end/node_modules/@babel/traverse/lib/context.js:107:19)
      at traverseNode (/Users/rkuykendall/projects/front-end/node_modules/@babel/traverse/lib/traverse-node.js:22:17)
      at NodePath.visit (/Users/rkuykendall/projects/front-end/node_modules/@babel/traverse/lib/path/context.js:88:52)
      at TraversalContext.visitQueue (/Users/rkuykendall/projects/front-end/node_modules/@babel/traverse/lib/context.js:86:16)
      at TraversalContext.visitMultiple (/Users/rkuykendall/projects/front-end/node_modules/@babel/traverse/lib/context.js:61:17)
      at TraversalContext.visit (/Users/rkuykendall/projects/front-end/node_modules/@babel/traverse/lib/context.js:107:19)
      at traverseNode (/Users/rkuykendall/projects/front-end/node_modules/@babel/traverse/lib/traverse-node.js:22:17)
      at NodePath.visit (/Users/rkuykendall/projects/front-end/node_modules/@babel/traverse/lib/path/context.js:88:52)
      at TraversalContext.visitQueue (/Users/rkuykendall/projects/front-end/node_modules/@babel/traverse/lib/context.js:86:16)
      at TraversalContext.visitSingle (/Users/rkuykendall/projects/front-end/node_modules/@babel/traverse/lib/context.js:65:19)
      at TraversalContext.visit (/Users/rkuykendall/projects/front-end/node_modules/@babel/traverse/lib/context.js:109:19)
      at traverseNode (/Users/rkuykendall/projects/front-end/node_modules/@babel/traverse/lib/traverse-node.js:22:17)
      at traverse (/Users/rkuykendall/projects/front-end/node_modules/@babel/traverse/lib/index.js:60:34)

@github-actions
Copy link
Contributor

Hi there! Thank you for opening this issue, but it has been marked as stale because we need more information to move forward. Could you please provide us with the requested reproduction or additional information that could help us better understand the problem? We'd love to resolve this issue, but we can't do it without your help!

@github-actions github-actions bot added the Stale label Oct 20, 2023
@github-actions
Copy link
Contributor

I'm afraid we need to close this issue for now, since we can't take any action without the requested reproduction or additional information. But please don't hesitate to open a new issue if the problem persists – we're always happy to help. Thanks so much for your understanding.

@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Oct 28, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests