top-level-await error using app directory

[niicojs]

Verify canary release

• I verified that the issue exists in the latest Next.js 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

[Fredkiss3]

I think it's a bug with ky-universal, maybe there is a top level await somewhere in the package, as you can see in the error description :

[niicojs]

There is, but this is totally valid and works fine without the app dir.
The bug is that it works fine without app dir, but not with it (even if ky is only used in pages dir)

[balazsorban44]

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
  },
}

[Renov4ted]

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

[vadzim]

for me this workaround works for pages, but not for api.
It's strange) I like top level await)

[Albosonic]

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:
this works:

import client from './apollo-client';
import { Inter } from 'next/font/google'
import styles from './page.module.css'

const inter = Inter({ subsets: ['latin'] })

export default async function Home() {
  const { data } = await client.query({
    query: gql`
      query {
        customer {
          id
        }
      }
    `,
  });
  
  return (
    <main className={styles.main}>
      <h1>My Component</h1>
    </main>
  )
}
`
this does not work and I get the top level experiment error:
import { gql } from "@apollo/client";
import client from './apollo-client';
import { Inter } from 'next/font/google'
import styles from './page.module.css'

const inter = Inter({ subsets: ['latin'] })

const { data } = await client.query({
  query: gql`
    query {
      customer {
        id
      }
    }
  `,
});

export default async function Home() {
  
  return (
    <main className={styles.main}>
      <h1>My Component</h1>
    </main>
  )
}
`


worth noting that my config still looks like this:
/** @type {import('next').NextConfig} */
const nextConfig = {
  experimental: {
    appDir: true,
  },
}

module.exports = nextConfig

[sagar285]

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

[vadzim]

@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 erverComponentsExternalPackages: ["mongoose"] option to the next config as a workaround

[azerum]

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

[theDanielJLewis]

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

[Piyusharora2003]

hii @theDanielJLewis can you tell which version of Mongoose you installed . I too getting same error

[manavm1990]

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

next.config.cjs

[hrithikvishwakarma001]

why am I not able to make any requests? Does anyone have any idea about it how to resolve this problem check my screenshot for reference and suggest to me what I should do to make request

[alexbaumgertner]

From Automattic/mongoose#13252 (comment)

Try to write in next.config.js file:

experimental: {
  appDir: true,
  serverComponentsExternalPackages: ["mongoose"],
},

It helped me.

More: https://nextjs.org/docs/app/api-reference/next-config-js/serverComponentsExternalPackages

[Piyusharora2003]

@hrithikvishwakarma001 do check the comment by @manavm1990 , it worked for me !

[Lantianyou]

This is not working for me when building a nextjs project. It would be really nice someone take a look. I am using node@18 and next@13.4.12. Even using the previousely mentioned WebPack work around.

[jaanli]

Also facing this @onefact -- I set experimental: { appDir: true }, in next.config.mjs and set "target": "ES2017", in tsconfig.json.

Added an example here: onefact/new.onefact.org@1519adc

This yields the error:

Failed to compile
./components/visualization/stocks.js
Error: 
  x top level await requires target to es2017 or higher and topLevelAwait:true for ecmascript
   ,-[/Users/me/projects/new.onefact.org/components/visualization/stocks.js:1:1]
 1 | import * as vg from "@uwdata/vgplot";
 2 | 
 3 | await vg.coordinator().exec(
   : ^^^^^
 4 |   vg.loadParquet("aapl", "https://uwdata.github.io/mosaic/data/stocks.parquet", { where: "Symbol = 'AAPL'" })
 5 | );
   `----

Caused by:
    Syntax Error

Any ideas how to debug? Thank you so much!!

[dirtycajunrice]

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.

[luchillo17]

Uh @jaanli isn't top level await supposed to be an ES2022 feature?

https://caniuse.com/?search=top%20level%20await

[ArianHamdi]

Same here.
I can't use top-level await in app directory even with enabled topLevelAwait in webpack config.

[luchillo17]

@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 tsconfig.json as well.

[ArianHamdi]

@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 tsconfig.json as well.

Hi @luchillo17.
Yes I am using typescript and also set target: ES2017 on the tsconfig.json is there anything else that I need to do?

Can type in the package.json affect this?

[luchillo17]

Uh @jaanli isn't top level await supposed to be an ES2022 feature?

https://caniuse.com/?search=top%20level%20await

@ArianHamdi Then let me mention it again, top-level await is an ES2022 feature, not an ES2017 one (ES2017 is for ESM, which is a requirement for top-level await), though Idk if that and the experimental Webpack config is enough.

[ArianHamdi]

Uh @jaanli isn't top level await supposed to be an ES2022 feature?
https://caniuse.com/?search=top%20level%20await

@ArianHamdi Then let me mention it again, top-level await is an ES2022 feature, not an ES2017 one (ES2017 is for ESM, which is a requirement for top-level await), though Idk if that and the experimental Webpack config is enough.

Thanks for your quick response.
I tried it using target:ES2022 and with both type:module and type:commonjs also tried webpack topLevelAwait and unfortunately none of this couldn't solve the problem.

Are you able to use top-level await in app directory?

[luchillo17]

Nope, but my setup is kind of layered, I have an Nx monorepo, with part of the code in a library, and some other in the app, I thought I couldn't because of Nx build executor, but maybe it was Webpack.

Tried again, and made it work, the issue is how you configure Next, this is what I did, and yes it seems ES2017 does work, but I guess it is because Next (or Webpack) automatically changes your tsconfig.json with "module": "esnext" as soon as you do this:

To clarify I did not touch the package.json at all, no "type": "module" in mine anywhere.

So the requirements are basically:

• Enable top-level await in Webpack through the next.config.js|ts as I did in the screenshot.
• Set "target": "ES2017" or higher in the tsconfig.json.
• Set "module": "es2022|esnext|system|node16|nodenext" or higher in the tsconfig.json, it depends on the project but Next or Webpack automatically sets it for you on run to esnext, I would lock it to es2022 or node16 instead of next variants.

[parsasabetz]

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 Error: TypeError: a.Z.find is not a function when trying to query the database. My configuration looks like this:

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...

[jaanli]

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 :)

[luchillo17]

@jaanli Good for you, you found another solution, even if it means dropping NextJS altogether.

@parsasabetz Try the moduleResolution as Node16, after that I would remove the serverComponentsExternalPackages to test if it has to do with the package not being processed by Webpack, afaik if you set module to esnext you have to do the same for moduleResolution.

[parsasabetz]

@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!
Anyways, is it worth it to go about Prisma now and rewrite the project with Prisma (got not much experience with it by the way...) now? Or should I just accept the fact that Next (or mongoose?) is forcing me to use ES5 for absolutely no clear reason?

[luchillo17]

After reading your issue again it is more likely to be mongoose's issue instead of NextJS, I don't use it so can't relate to the issue, I usually use MongoDB directly, in fact, I haven't used withNextIntl, and esmExternals is also new to me, I would probably suggest you ask in Mongoose and see if there's a similar type error in their issues.

[timneutkens]

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:

• You can remove topLevelAwait: true from the webpack configuration.
• Turbopack support top level await by default
• Top level await works with TypeScript if you add target: "ES2017" to the tsconfig.json
  • After Improve top level await coverage #64508 lands it'll automatically write target: "ES2017" whenever target is not specified. This is set as suggested so it won't update existing target values.
• There's a bug in React that is causing client components using top level await to fail loading. @gnoff is looking into it.