ModuleNotFoundError: Could not find module in path: '<package/subpath>' relative to '<local-path/file>'

🐛 bug report

Preflight Checklist

• I have read the Contributing Guidelines for this project.
• I agree to follow the Code of Conduct that this project
  adheres to.
• I have searched the issue tracker for an issue that matches the one I want
  to file, without success. I've found similar issues that may be related, but details differ.

Description of the problem

When importing a dependency from a subpath like @workday/canvas-kit-react/tabs, we get this error:

The package name is @workday/canvas-kit-react, and the subpath is /tabs.

I looked at similar issues and there are a couple things that might make this unique.

• it goes away if I keep editing, or in some cases, click on the refresh button for the preview
• it only happens on a subpath that we export using export *
• I was unable to repro with a similar subpath that doesn't use export *
• we found a workaround: don't use the subpath

In our case, we happen to export everything as a subpath and directly off the main package (no subpath). If we drop our subpath, the same import statement works without throwing this error.

Using a subpath is optional for our library, but often preferred. We could also avoid export * but it's highly advantageous for exposing new exports.

Note this issue, #6473 from @pksjce, has this same issue but their example is different. At least, it's logging that a module is not found in their package from another module in their package. It is like ours though because it involves 1) a subpath and 2) they're also using export * under the hood.

In our case, our local source is having trouble with the import from our package. We can work around it by refreshing the preview or waiting a while. If we keep making edits though, the issue comes back eventually. I did a lot of testing and it's hard to be really specific what changes will cause it, but we're usually editing the JSX and adding and removing JSX elements.

Interestingly, this happened a lot last week on Thursday, but today it happens less often and it recovers more easily. Today I haven't had to to click refresh, I just make another small edit in the file to trigger an update and it resolves on its own. Of course, it comes back eventually though.

In case it helps, here are links to where we export our modules:

main exports (no subpaths, uses export *): https://github.com/Workday/canvas-kit/blob/master/modules/react/index.ts
subpath with the issue (uses export *): https://github.com/Workday/canvas-kit/blob/master/modules/react/tabs/index.ts
subpath without the issue (doesn't use export * except for types): https://github.com/Workday/canvas-kit/blob/master/modules/react/button/index.ts

How has this issue affected you? What are you trying to accomplish?

I'm trying to live-code in a workshop with CodeSandbox but in our last session, any edits to our JSX or TypeScript caused this error to come up and we'd have to click the refresh button. It was extremely cumbersome to use.

We also get bug reports with CodeSandbox as the preferred tool to repro. We expect this will be come up for our users and get in their way.

To Reproduce

Link to sandbox: subpath-import-problem-m2zy8e (optional)

I would get this constantly at times (any change) but then it's not coming up right now reliably. I recommend trying to comment the code block from line 12-19 (the <Tabs /> JSX) and/or commenting out the import for Tabs on line 4. In the past I've gotten this just from editing unrelated code like the text of the PrimaryButton.

If you change the import on line 4 to not use the subpath, it won't have this problem at all: import { Tabs } from "@workday/canvas-kit-react";. This is our workaround for now.

Your Environment

Software	Name/Version
Сodesandbox	932582143
Browser	Chrome
Operating System	MacOS

Start with the linked CodeSandbox reproduction, then compare modules/react/index.ts, modules/react/tabs/index.ts, and modules/react/button/index.ts, focusing on subpath imports that use export *. Confirm whether edits trigger the ModuleNotFoundError and whether refreshing or importing from the main package avoids it. Done means the subpath import remains reliable during live edits without refreshes.