next/dynamic with ssr: false | changed behaviour / breaking builds in Next 13

[maxcbc]

Verify canary release

• I verified that the issue exists in the latest Next.js canary release

Provide environment information

Operating System:
Platform: darwin
Arch: x64
Version: Darwin Kernel Version 22.1.0: Sun Oct 9 20:14:54 PDT 2022; root:xnu-8792.41.9~2/RELEASE_X86_64
Binaries:
Node: 16.18.1
npm: 7.20.2
Yarn: 1.22.19
pnpm: N/A
Relevant packages:
next: 13.0.7-canary.4
eslint-config-next: 12.1.0
react: 18.2.0
react-dom: 18.2.0

Which area(s) of Next.js are affected? (leave empty if unsure)

Dynamic imports (next/dynamic)

Link to the code that reproduces this issue

https://github.com/maxcbc/nextjs-13-dynamic-bug

To Reproduce

1. Clone repo
2. npm install
3. npm run fake-deps
4. npm run build

Investigation Points

1. npm install next@12.3.4 --no-save
2. Update line 1 of ./components/dynamic-thing/some-client-side-only-component.tsx to import foo from 'fake-dependency-1/browser'
3. npm run build
4. cat .next/server/pages/index.js.nft.json | grep "fake"

Adding main property

1. git checkout ./components/dynamic-thing/some-client-side-only-component.tsx
2. npm install
3. Add "main": "browser.js", to each of the fake dependency package.json files
4. npm run fake-deps
5. npm run build
6. cat .next/server/pages/index.js.nft.json | grep "fake"

Describe the Bug

Broken somewhere between 12.3.4 and 13.0.6.

Module not found errors in build when running the above.

Can be fixed by adding a main property in the package.json of the 'missing' modules.

Expected Behavior

In the example above ./some-client-side-only-component.tsx should never be required when compiling serverside code.
There should be no trace of them in .next/server after a build.

Which browser are you using? (if relevant)

No response

How are you deploying your application? (if relevant)

No response

[huozhi]

Can you provide a minimal reproduction to show how you use next/dynamic with the package? The information is quite limited from the description

[maxcbc]

@huozhi Apologies, I've now updated the issue with an example repo and instructions.

[huozhi]

Seems like a module resolving issue instead of a next/dynamic issue, removing the next/dynamic label for re-triaging later

[maxcbc]

@huozhi yeah sorry, logically at the bug is probably somewhere in swc, rather than dynamic.

[maxcbc]

Interestingly the bug is not present in 13.0.2-canary.2, but is there in 13.0.2-canary.3.
But in github the 2 tags are identical. v13.0.3-canary.2...v13.0.2-canary.3

[maxcbc]

So looking at it I think the error comes from this commit, 21b6654 @huozhi .
Prior to this commit the loader method was stripped when compiling server side with ssr: false, meaning import statements in the loader were not bundled (nor their import statements). This is now changed as it treats it as a server component even though the ssr property is false.

Is this intentional? I'm not 100% up to speed on server components so I may just be missing the logic here.

[huozhi]

Thanks for the investigation! I got what you mean why it appears in the trace and can't resolve with browser field. Filed #43974 to fix it

[maxcbc]

Thanks so much.

Apologies again for the rather opaque description of the bug, it all made sense in my head. 🙂

[github-actions]

This closed issue has been automatically locked because it had no new activity for a month. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.