Support for module: 'ES2022'

[neilenns]

Troubleshooting

1. Does tsc have the same output? If so, please explain why this is incorrect behavior

No.

1. Does your Rollup plugin order match this plugin's compatibility?

n/a

1. Can you create a minimal example that reproduces this behavior? Preferably, use this environment for your reproduction

Yes. Minimal repo environment

What happens and why it is incorrect

When building using the node16-strictest-esm standard tsconfig the following error is generated:

[!] (plugin rpt2) RollupError: Incompatible tsconfig option. Module resolves to 'ES2022'. This is incompatible with Rollup, please use 'module: "ES2015"', 'module: "ES2020"', or 'module: "ESNext"'.

Environment

n/a, reproduces in the minimal environment

Versions

  System:
    OS: Windows 10 10.0.22621
    CPU: (12) x64 AMD Ryzen 5 5600X 6-Core Processor
    Memory: 16.43 GB / 31.91 GB
  Binaries:
    Node: 16.19.0 - C:\Program Files\nodejs\node.EXE
    npm: 8.19.3 - C:\Program Files\nodejs\npm.CMD
  npmPackages:
    rollup: ^3.13.0 => 3.13.0
    rollup-plugin-typescript2: ^0.34.1 => 0.34.1
    typescript: ^4.9.5 => 4.9.5

rollup.config.js

:

import typescript from 'rollup-plugin-typescript2';
import resolve from '@rollup/plugin-node-resolve';
import css from 'rollup-plugin-import-css';
import copy from 'rollup-plugin-copy';
import commonjs from '@rollup/plugin-commonjs';

export default {
  input: 'MyInstrument.tsx',
  output: {
    dir: 'build',
    format: 'es'
  },
  plugins: [
    css({ output: 'MyInstrument.css' }), 
    resolve(), 
    commonjs(),
    typescript(),
    copy({
      targets: [
        { src: '*.html', dest: 'build'}
      ]
    })
  ],

  onwarn: function(/** @type {{ code: string; message: any; }} */ warning) {
    // Skip warnings caused by TypeScript's use of "this". Cannot find *any* good
    // information on why this happens. 
    if ( warning.code === 'THIS_IS_UNDEFINED' ) { return; }

    // console.warn everything else
    console.warn( warning.message );
  }
}

tsconfig.json

:

/* This config comes from https://microsoft.github.io/msfs-avionics-mirror/docs/getting-started/setting-up-your-environment */
{
  "extends": "@tsconfig/node16-strictest-esm/tsconfig.json",
  "compilerOptions": {
    "incremental": true, /* Enables incremental builds */
    "outDir": "build", /* Sets the output folder to ./build */
    "jsxFactory": "FSComponent.buildComponent", /* Required for FSComponent framework JSX */
    "jsxFragmentFactory": "FSComponent.Fragment", /* Required for FSComponent framework JSX */
    "jsx": "react" /* Required for FSComponent framework JSX */
  }
}

[agilgur5]

Feature request, not a bug

When building using the node16-strictest-esm standard tsconfig the following error is generated:

[!] (plugin rpt2) RollupError: Incompatible tsconfig option. Module resolves to 'ES2022'. This is incompatible with Rollup, please use 'module: "ES2015"', 'module: "ES2020"', or 'module: "ESNext"'.

Per the error and the docs, rpt2 does not currently support module: 'ES2022' -- that is a recent feature after all 😅

Workaround

As a workaround, you can probably use module: 'ESNext'. Or, if you're not using top-level await, 'ES2020' should be fine.

Supporting module: 'ES2022'

The TSConfig Reference was unfortunately not very helpful in describing the differences between the 'ES2020' and the 'ES2022' options. I used to contribute a lot to it, but it hasn't been maintained too well since @orta left MSFT 😕

Fortunately, the TS 4.5 Release Notes describe the option. Basically all it does is add support for top-level await.

This is probably fine for rpt2 to support, but it would be good to add a Rollup integration test for this to make sure that it doesn't break Rollup. I imagine newer versions of Rollup / Acorn (the AST processor Rollup uses) will be fine, but we may also need to add an error check for older versions of Rollup.

PR welcome 🙂

[ssjarchon]

This is a major issue for me; I am using Top-Level await, and due to some other considerations I cannot use ESNext. I have worked around it for now by simply adding it to the list of checked modules types, but I'd really like something merged sooner rather than later so that this is easier for my fellow developers on my project. Hopefully this is helpful to anyone else.

Rollup-Plugin-Typescript2.cjs.js Line 27907

    const preParsedTsConfig = tsModule.parseJsonConfigFileContent(mergedConfig, tsModule.sys, baseDir, getOptionsOverrides(pluginOptions), configFileName);
    const compilerOptionsOverride = getOptionsOverrides(pluginOptions, preParsedTsConfig);
    const parsedTsConfig = tsModule.parseJsonConfigFileContent(mergedConfig, tsModule.sys, baseDir, compilerOptionsOverride, configFileName);
    const module = parsedTsConfig.options.module;
    if (module !== tsModule.ModuleKind.ES2015 && module !== tsModule.ModuleKind.ES2020 && module !== tsModule.ModuleKind.ESNext && module!== tsModule.ModuleKind.ES2022)
        context.error(`Incompatible tsconfig option. Module resolves to '${tsModule.ModuleKind[module]}'. This is incompatible with Rollup, please use 'module: "ES2015"', 'module: "ES2020"', or 'module: "ESNext"'.`);
    printDiagnostics(context, convertDiagnostic("config", parsedTsConfig.errors), pretty);
    context.debug(`built-in options overrides: ${JSON.stringify(compilerOptionsOverride, undefined, 4)}`);
    context.debug(`parsed tsconfig: ${JSON.stringify(parsedTsConfig, undefined, 4)}`);
    return { parsedTsConfig, fileName };

[agilgur5]

but I'd really like something merged sooner rather than later so that this is easier for my fellow developers on my project.

per my previous comment above and the labels on this issue, PR welcome 🙂

[ezolenko]

I committed the change for ES2022 along with some dependency updates, but unittests are now falling over (because of ts-jest update I expect). @agilgur5 could you take a look when you have time? Otherwise I'll revert dependency updates and make a release with just module type change.

[ezolenko]

In 0.35.0 now

[agilgur5]

This is probably fine for rpt2 to support, but it would be good to add a Rollup integration test for this to make sure that it doesn't break Rollup. I imagine newer versions of Rollup / Acorn (the AST processor Rollup uses) will be fine, but we may also need to add an error check for older versions of Rollup.

Just checked this and it seems like Rollup has been supporting top-level await (TLA) for a while actually, since 1.29.0.

rpt2 supports down to 1.26.3, so ideally we should add a warning for versions older than 1.29.0 that try to use module: 'ES2022'. This requires a couple lines of code as we'd have to pass versioning through to the parseTsConfig call and then check both.

Right now could probably argue that it is not worth the effort to implement that check (although it would only be a couple of lines) given how old that version of Rollup is and how many features of rpt2 already ask for (much) newer versions, but thought I should at least document that for posterity.

[ezolenko]

That rollup support version is not based on much anymore aside from history and I doubt it is needed (or even works). We can bump that version to something newer in 0.36

[agilgur5]

Yea I'm well aware of that, but we haven't needed to bump it so far. We can proactively bump it to Rollup 2.60 (that is the maximum feature set we rely on) though to get ahead of some tech debt. That will likely cause a Node bump (though we don't currently specify engines), which may require a TS bump as well for consistency.

[agilgur5]

Pure coincidence, but I did stumble upon one of the reasons for the Rollup version, so thought I'd jot that down here for posterity. 1.19.0 introduced the emitFile API in rollup/rollup#2999, and that was used for #180 / #181. Plus some more related upgrades in #184 and #190. 1.26.3 also happens to be the latest version from around that time period.

But yea there's a decent bit of deprecations and backward compat workarounds alongside a version bump. Might get to that this week.