-
Notifications
You must be signed in to change notification settings - Fork 26.7k
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
top-level-await error using app directory #43382
Comments
There is, but this is totally valid and works fine without the app dir. |
This is related to #42741 Here is a workaround: /** @type {import("next").NextConfig} */
module.exports = {
experimental: { appDir: true },
webpack(config) {
config.experiments = { ...config.experiments, topLevelAwait: true }
return config
},
} |
I don't have that section in my project where to find that |
for me this workaround works for pages, but not for api. |
Also building a nextJS 13 app. With apollo, and saw this error. What fixed it for me was moving my my apollo client query into the component. Rather than lexically before it. eg:
|
if there is anyone who is able to findout the way to connect next.js 13 to mongodb database pls pin the anaswer over here , this is an big issue now |
@sagar285 here https://stackoverflow.com/questions/75697312/import-mongoose-lib-in-api-directory-in-next-js-13-2-app-directory-gives-error there's an advise to add |
If you don't want to use experimental features in production, you can downgrade to mongoose 6.11.1 By inspecting git blame of bson repo I've found that top-level await was introduced in version 5 mongoose started using bson@5 since version 7, and 6.11.1 is the latest 6.x.y version |
I was having this same problem and then downgraded Mongoose to version 6 (and downgraded Typegoose to version 10) and the problem went away! Thank you! I was pulling out my hair on this one! And here's my relevant discussion about this in the Mongoose repo: Automattic/mongoose#13419 |
hii @theDanielJLewis can you tell which version of Mongoose you installed . I too getting same error |
|
From Automattic/mongoose#13252 (comment) Try to write in experimental: {
appDir: true,
serverComponentsExternalPackages: ["mongoose"],
}, It helped me. More: https://nextjs.org/docs/app/api-reference/next-config-js/serverComponentsExternalPackages |
@hrithikvishwakarma001 do check the comment by @manavm1990 , it worked for me ! |
Also facing this @onefact -- I set Added an example here: onefact/new.onefact.org@1519adc This yields the error:
Any ideas how to debug? Thank you so much!! |
This is still an issue as of the latest canary. Just with mongodb pure, you have to disable server minification. Hopefully this is addressed soon. |
Uh @jaanli isn't top level await supposed to be an |
Same here. |
@ArianHamdi are you using TS? if you do you'll need more than that config in Webpack, you'll need to configure it in the |
Hi @luchillo17. Can |
@ArianHamdi Then let me mention it again, top-level await is an |
Thanks for your quick response. Are you able to use top-level await in |
Tried again, and made it work, the issue is how you configure Next, this is what I did, and yes it seems To clarify I did not touch the So the requirements are basically:
|
I'm trying to get mongoose to work in production without having to use the ES5 syntax and I've tried every possible combination of these configurations you mentioned. I still get a weird module.exports = withNextIntl({
experimental: {
esmExternals: "loose",
serverComponentsExternalPackages: ["mongoose"],
},
webpack: (config) => {
config.experiments ??= {}
config.experiments.topLevelAwait = true
console.log(config)
return config
},
logging: {
fetches: {
fullUrl: true,
},
},
}) And my tsconfig is as: {
"compilerOptions": {
"target": "ES2020",
"lib": ["dom", "dom.iterable", "esnext"],
"allowJs": true,
"skipLibCheck": true,
"strict": true,
"noEmit": true,
"esModuleInterop": true,
"module": "esnext",
"moduleResolution": "bundler",
"resolveJsonModule": true,
"isolatedModules": true,
"jsx": "preserve",
"incremental": true,
"plugins": [
{
"name": "next"
}
],
"paths": {
"@/*": ["./src/*"],
"@/public": ["./public"]
}
},
"include": ["next-env.d.ts", "**/*.ts", "**/*.tsx", ".next/types/**/*.ts"],
"exclude": ["node_modules"]
} Any ideas how to make this work? I do not want to use the ES5 syntax at any cost... |
Just FYI, I had to switch from NextJS to Vite (and Vike, for SSR/ISR) because of the lack of support on this issue specifically. thankfully Claude.ai and GPT-4 make it easy to migrate :) |
@jaanli Good for you, you found another solution, even if it means dropping NextJS altogether. @parsasabetz Try the |
@luchillo17 I still can't figure it out... I've done everything and honestly at this point it seems that it's not just lack of support, it's anti-support lol! |
After reading your issue again it is more likely to be |
Since Next.js 13.4.5 webpack has top level await support enabled by default. Similarly Turbopack supports top level await by default as well. In writing additional tests in #64508 I found that client components are missing some kind of handling for async modules so I've raised that to @gnoff who is going to have a look on the React side of module loading. The PR I opened also gets rid of a warning shown by webpack, but it still works fine without that change (i.e. on 14.2) TLDR:
|
## What? - Changes webpack output target to `es6` (required for `async function` output) - Adds tests for top level await in server components and client components (App Router) - Converted the async-modules tests to `test/e2e` - Has one skipped test that @gnoff is going to look into. This shouldn't block merging this PR 👍 Adds additional tests for top level `await`. Since [Next.js 13.4.5](https://github.com/vercel/next.js/releases/tag/v13.4.5) webpack has top level await support enabled by default. Similarly Turbopack supports top level await by default as well. TLDR: You can remove `topLevelAwait: true` from the webpack configuration. In writing these tests I found that client components are missing some kind of handling for top level await (async modules) so I've raised that to @gnoff who is going to have a look. <!-- Thanks for opening a PR! Your contribution is much appreciated. To make sure your PR is handled as smoothly as possible we request that you follow the checklist sections below. Choose the right checklist for the change(s) that you're making: ## For Contributors ### Improving Documentation - Run `pnpm prettier-fix` to fix formatting issues before opening the PR. - Read the Docs Contribution Guide to ensure your contribution follows the docs guidelines: https://nextjs.org/docs/community/contribution-guide ### Adding or Updating Examples - The "examples guidelines" are followed from our contributing doc https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md - Make sure the linting passes by running `pnpm build && pnpm lint`. See https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md ### Fixing a bug - Related issues linked using `fixes #number` - Tests added. See: https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ### Adding a feature - Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. (A discussion must be opened, see https://github.com/vercel/next.js/discussions/new?category=ideas) - Related issues/discussions are linked using `fixes #number` - e2e tests added (https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs) - Documentation added - Telemetry added. In case of a feature if it's used or not. - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ## For Maintainers - Minimal description (aim for explaining to someone not on the team to understand the PR) - When linking to a Slack thread, you might want to share details of the conclusion - Link both the Linear (Fixes NEXT-xxx) and the GitHub issues - Add review comments if necessary to explain to the reviewer the logic behind a change ### What? ### Why? ### How? Closes NEXT- Fixes # --> Closes NEXT-3126 Fixes #43382
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. |
Verify canary release
Provide environment information
I'm using ky-universal in my project.
next@latest
node LTS (18)
What browser are you using? (if relevant)
No response
How are you deploying your application? (if relevant)
pnpm
Describe the Bug
Using pages directory, everything works fine but as soon as I define experimental.appDir = true in next.config.js I have this error:
Module parse failed: The top-level-await experiment is not enabled (set experiments.topLevelAwait: true to enabled it)
You may need an appropriate loader to handle this file type, currently no loaders are configured to process this file.
See https://webpack.js.org/concepts#loaders
Error: The top-level-await experiment is not enabled (set experiments.topLevelAwait: true to enabled it)
Expected Behavior
Just activating experimental pages should not alter anything in pages.
Link to reproduction - Issues with a link to complete (but minimal) reproduction code will be addressed faster
https://stackblitz.com/edit/nextjs-vwd7jz
To Reproduce
Example available here: https://stackblitz.com/edit/nextjs-vwd7jz
Just remove app dir in next config and it will work again.
NEXT-3126
The text was updated successfully, but these errors were encountered: