Unit tests break when using @headless/ui-package
#54286
Comments
This was referenced Aug 19, 2023
|
I have added a repro here: https://github.com/weyert/nextjs-jest-modularize-imports But when you try to run tests its failing with the following error: |
This was referenced Aug 28, 2023
5 tasks
kodiakhq bot
pushed a commit
that referenced
this issue
Aug 30, 2023
) ## Initial Pass The initial pass applies to all user code. If an import (`foo`) matches one of the packages from our list, say: ```js // user code import { a } from 'foo' import { otherThings } from './code' ``` The initial pass transforms it into: ```js // user code import { a } from '__barrel_optimize__?names=a!=!foo' import { otherThings } from './code' ``` ## Barrel Optimizations This `__barrel_optimize__` loader is used to optimize the imports of "barrel" files that have many re-exports. Currently, both Node.js and Webpack have to enter all of these submodules even if we only need a few of them. For example, say a file `foo.js` with the following contents: ```js export { a } from './a' export { b } from './b' export { c } from './c' ... ``` If the user imports `a` only, this loader will accept the `names` option to be `['a']`. Then, it request the `__barrel_transform__` SWC loader to load `foo.js` (via `this.loadModule` Webpack API) and receive the following info: ```js export const __next_private_export_map__ = '[["./a","a","a"],["./b","b","b"],["./c","c","c"],...]' ``` The export map, generated by SWC, is a JSON that represents the exports of that module, their original file, and their original name (since you can do `export { a as b }`). Then, this loader can safely remove all the exports that are not needed and re-export the ones from `names`: ```js export { a } from './a' ``` That's the basic situation and also the happy path. ## Wildcard Exports For wildcard exports (e.g. `export * from './a'`), it becomes a bit more complicated. Say `foo.js` with the following contents: ```js export * from './a' export * from './b' export * from './c' ... ``` If the user imports `bar` from it, SWC can never know which files are going to be exporting `bar`. So, we have to keep all the wildcard exports and do the same process recursively. This loader will return the following output: ```js export * from '__barrel_optimize__?names=bar&wildcard!=!./a' export * from '__barrel_optimize__?names=bar&wildcard!=!./b' export * from '__barrel_optimize__?names=bar&wildcard!=!./c' ... ``` The "!=!" tells Webpack to use the same loader to process './a', './b', and './c'. After the recursive process, the "inner loaders" will either return an empty string or: ```js export * from './target' ``` Where `target` is the file that exports `bar`. ## Non-Barrel Files If the file is not a barrel, we can't apply any optimizations. That's because we can't easily remove things from the file. For example, say `foo.js` with: ```js const v = 1 export function b () { return v } ``` If the user imports `b` only, we can't remove the `const v = 1` even though the file is side-effect free. In these caes, this loader will simply re-export `foo.js`: ```js export * from './foo' ``` Besides these cases, this loader also carefully handles the module cache so SWC won't analyze the same file twice, and no instance of the same file will be accidentally created as different instances. --- - [x] Disable this loader for Jest - [x] Add tests for SWC loader caching - [x] Add tests for external modules - [x] Add tests for pages - [x] Add tests for recursive `export *`s --- Closes #54038, closes #54286.
|
I have the same issue. Is it fixed already? Can still reproduce in 1.7.17 |
|
Works for me in the last canary version |
|
What's the workable solution here? |
Waiting for 13.4.20 to be released! It's been fixed for weeks on canary, but for whatever reasons, we've had no new production release for over 3 weeks, which is annoying as there's a ton of fixes since .19, and we dont want to run a canary. ( as such we are currently stuck on .12 .....) |
|
Cannot find module 'modularize-import-loader?name=Tab&join=./components/tabs/tabs!@headlessui/react' from 'src/components_data/devtools/PantomathDevtools.tsx' |
|
This closed issue has been automatically locked because it had no new activity for 2 weeks. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Verify canary release
Provide environment information
Operating System: Platform: darwin Arch: arm64 Version: Darwin Kernel Version 22.6.0: Wed Jul 5 22:22:05 PDT 2023; root:xnu-8796.141.3~6/RELEASE_ARM64_T6000 Binaries: Node: 18.14.0 npm: 8.19.3 Yarn: 1.22.19 pnpm: 8.6.12 Relevant Packages: next: 13.4.19 eslint-config-next: 13.4.19 react: 18.2.0 react-dom: 18.2.0 typescript: 4.9.5 Next.js Config: output: N/AWhich area(s) of Next.js are affected? (leave empty if unsure)
Jest (next/jest)
Link to the code that reproduces this issue or a replay of the bug
https://github.com/weyert/nextjs-jest-modularize-imports
To Reproduce
import { Dialog, Transition } from '@headlessui/react'Describe the Bug
When you try to run the unit tests you can get an error after upgrading to 13.4.9:
Expected Behavior
I would expect unit tests to pass when not making any code changes but only upgrading to a newer version of Next when no breaking changes are listed in the release notes
Which browser are you using? (if relevant)
Edge
How are you deploying your application? (if relevant)
Other platform
The text was updated successfully, but these errors were encountered: