Typically standard doesn't enable this type of support until it is in stage 4 (https://github.com/standard/standard#how-do-i-use-experimental-javascript-es-next-features).

Regarding Node.js support, it has been supported prior to 14.8.0, but just behind a command line flag. Even with it unflagged, Node.js still documents the support has experimental, of course (https://nodejs.org/dist/latest-v14.x/docs/api/esm.html#esm_experimental_top_level_await). I'm not sure why it is still marked as experimental unless they are waiting for it to enter either Stage 4 or it become part of the standard.

Thanks @dougwilson - this is fair enough and it's one of the downsides to not putting experimental features behind flags.

My only counterpoint here is for the sake of pragmatism: if it's not behind a flag, people will use it without checking whether it's experimental and while this isn't in any way the linters fault, the linter may be blamed regardless.

To clarify, I am not a member of this project and cannot make decisions etc. I was just trying to help by connecting your question to the project's written policy.

Thanks for the suggestion @davidmarkclements and for the helpful discussion @dougwilson. Unfortunately, there's not much we can do to easily enable support for this. The language parser used by ESLint has a policy of not supporting features until Stage 4.

So this is not solvable unless we decide to start shipping the babel-eslint parser instead of the default ESLint one, which is a much larger decision to make.

This issue will be fixed once the feature enters Stage 4.

Thanks @dougwilson and thanks @feross for a useful discussion ✌️

Hey folks I'm using standard to lint some Node 16 ESM files and I'm having an issue with TLA. Any solutions?

@Ethan-Arrowood I'm ignoring the files containing top-level await for now:

// package.json
"standard": {
  "ignore": [
    "**/the-filename.js"
  ],
}

Top level await has been stage 4 for a while, is there any fix?

@extremeheat You can track ESLint progress here: eslint/eslint#14632
It'll be released in ESLint 8.0.
Once ESLint is updated, Standard surely will follow shortly after.

Nothing firm. We will likely release a beta within the next two weeks and the final version will depend on the feedback we get during the beta.

Hopefully this is happening soon! 🎉

With the current code, we can't upgrade to eslint@8 when it will be released.
We're working on it: standard/standard-engine#234

I guess we could release standard@17 with eslint@8 to support all the new features, including Top-level await.
Also the first v8.0.0 beta prerelease has been published! (see: eslint/eslint#14872 and https://eslint.org/blog/2021/08/eslint-v8.0.0-beta.0-released).

With AWS Lambda now supporting top level await (https://aws.amazon.com/blogs/compute/using-node-js-es-modules-and-top-level-await-in-aws-lambda/) I imagine a lot more will run into this parsing error. It looks like eslint@8 (https://github.com/eslint/eslint/releases) has been released.

@willfarrell you can follow Standard 17 (which uses ESLint 8) progress here: standard/eslint-config-standard#208

Prerelease 17.0.0-0 of standard is now released, containing ESLint 8 support, which should fix this issue. See: https://github.com/standard/standard/releases/tag/v17.0.0-0

Would love if you could all test this and report back here if this is still an issue 🙏 We'll reopen this if its still an issue.

@voxpelli Something wrong is not right

// main.js
await new Promise(resolve => resolve())

$ standard --version 
17.0.0-0
$ eslint --version     
v8.8.0
$ standard .\main.js
standard: Use JavaScript Standard Style (https://standardjs.com)
  .\main.js:1:1: Parsing error: Cannot use keyword 'await' outside an async function (null)

Furthermore, VSCode (standard.vscode-standard v2.0.1) don't show Standard errors anymore.

@NemoStein Right, thanks, I'll reopen. Have you tested in plain ESLint 8 and seen if it works there? Maybe we need to explicitly allow it?

In regards to the VSCode extension, that one needs an update, I highlighted that in standard/eslint-config-standard#208 now 🙏

just had a quick look and standard 17 doesn't support class instance fields, either (which eslint 8 does)

class Test {
  something = 1
}

export default Test

$ standard instance-field.js
standard: Use JavaScript Standard Style (https://standardjs.com)
  /Users/lloyd/Documents/instance-field:2:13: Parsing error: Unexpected token = (null)

@voxpelli Ok, here goes my 2 cents.
Using only ESLint, if you don't set the parserOptions.ecmaVersion to "latest" it also triggers the error

// .eslintrc.js

module.exports = {
  env: {
    es2021: true,
  },
  parserOptions: {
    ecmaVersion: 'latest', // <--- This line!!!
    sourceType: 'module'
  }
}

// main.js

await new Promise(resolve => resolve())

With parserOptions.ecmaVersion: "latest"

$ eslint .\main.js
$

Without

$ eslint .\main.js

.\main.js
  1:1  error  Parsing error: Cannot use keyword 'await' outside an async function

✖ 1 problem (1 error, 0 warnings)

$

@NemoStein Yeah, I arrived at the same conclusion, will merge and release standard/eslint-config-standard#212 when another maintainer gives me a review 👍

@NemoStein @75lb We just released 17.0.0-1 with a fix for this.

Unless standard/eslint-config-standard-jsx#43 overrides that fix, then it should work now, else we'll try to get a fix in for that issue and releases a 17.0.0-2 tomorrow.

Both me and @divlo needs some sleep now 😅

Unless standard/eslint-config-standard-jsx#43 overrides that fix

Sadly it does, but I can confirm that updating the eslint-config-standard-jsx/eslintrc.json to "ecmaVersion": 2022 works.

17.0.0-2 should finally be fixing this + we now have tests that ensures that ensures that's the case