Skip to content

@rollup/plugin-typescript - Support for TypeScript 7 #2016

Description

@fregante
  • Rollup Plugin Name: @rollup/plugin-typescript
  • Rollup Plugin Version: 12.3.0

It seems that the plugin hasn't seen any updates since 2025, it would be great to see support for TypeScript 7 (keywords: tsgo, ts7) since it finally launched:

I've been using @rollup/plugin-sucrase for speed improvements but I'd love to go back to the native TS version once it's supported by @rollup/plugin-typescript

Last requested in:

Activity

  1. Khoeckman commented on Jul 20, 2026

    @Khoeckman
    C:\Users\kyleh\PP_FILE_STORE\packz_ai_assistant>npm run build
    
    > packz-ai-assistant-cloudflow@0.0.1 build
    > rollup -c
    
    [!] TypeError: Cannot read properties of undefined (reading 'ES2015')

    I can no longer build my code because of @rollup/plugin-typescript not supporting "typescript": "^7.0.2". Forcing me to stay on TS6

  2. lwmacct commented on Aug 5, 2026

    @lwmacct

    I reproduced the failure with @rollup/plugin-typescript@12.3.0 and typescript@7.0.2:

    TypeError: Cannot read properties of undefined (reading "ES2015")
    

    The immediate cause is that TypeScript 7 exposes only version metadata from the typescript package root, while the plugin eagerly imports that package and reads ModuleKind at module scope.

    Changing the import to typescript/unstable/sync would not provide full compatibility. The new API exposes ModuleKind, but it does not expose several legacy APIs currently used by the plugin, including:

    • createWatchProgram
    • createWatchCompilerHost
    • createEmitAndSemanticDiagnosticsBuilderProgram
    • parseJsonConfigFileContent
    • sys
    • program.emit

    The missing programmatic emit functionality is being tracked upstream:

    I also tested the official TypeScript 7 and TypeScript 6 side-by-side dependency layout in a real Rollup project:

    {
      "devDependencies": {
        "@typescript/native": "npm:typescript@^7.0.2",
        "typescript": "npm:@typescript/typescript6@^6.0.2"
      }
    }

    The verification results were:

    • pnpm exec tsc --version reports 7.0.2
    • importing typescript provides the TypeScript 6 Compiler API, including ModuleKind and createWatchProgram
    • pnpm typecheck passes using TypeScript 7
    • pnpm build passes using the TypeScript 6 Compiler API through @rollup/plugin-typescript

    This is a working migration path, but it is not native TypeScript 7 support.

    There also appears to be a related issue with the documented custom typescript option from microsoft/typescript-go#2012: eager imports of the default typescript package prevent that option from cleanly selecting @typescript/typescript6 when typescript@7 is installed under its normal package name.

    Would the maintainers accept a short-term PR that:

    1. detects TypeScript 7 and reports an actionable compatibility error;
    2. documents and tests the official side-by-side setup;
    3. consistently uses the supplied compiler instance where possible;
    4. tracks full native support separately until the TypeScript 7 emit APIs are available?
  3. added a commit that references this issue on Aug 17, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions