Support for Arbitrary Module Identifiers

This changes ExportSpecifier#exported and ImportSpecifier#imported to be potentially string literals, I believe. And may require a change to the AST converter or even estree itself (if we require Identifier nodes to represent actual identifiers). I don't know for sure because ts-ast-viewer still gives a parser error on export { a as "a" };.

@Josh-Cena you're not wrong! I'd just forgotten that we hadn't done that yet cos I'd remembered seeing it in the spec ages ago.

Search Ancestor Configuration Files for Project Ownership

This change was reverted in the RC version. See:

• https://devblogs.microsoft.com/typescript/announcing-typescript-5-6-rc/#what%E2%80%99s-new-since-the-beta0
• Revert of Search ancestor and its references for default projects #57196 microsoft/TypeScript#59634

If ever it can help someone else : Using TS 5.6.2 made the onSave feature of VSCode's extension dbaeumer.vscode-eslint extremely slow (more than 10s) when it worked quite fast directly from bash

Hello @bradzacher 👋
Thanks a lot for your great work! 🙌
Is there any estimate on when we might get support for TypeScript 5.6? 🙏

We're currently blocked on microsoft/rushstack#4919

We haven't had the bandwidth to investigate and try helping them fix it. If anyone is so motivated - fixing that would unblock us and allow us to support 5.6

I took a look and sent microsoft/rushstack#4973 to api-extractor, which I believe should unblock you if you pull the patch in locally (which you've had to do previously).

If the rushstack api-extractor is no longer a blocker; will you release a new version with TypeScript 5.6 support soon?

You bet 🙂 just merged the PR and should release soon. Will post back here as soon as we have something.

✨ [email protected] ✨

Will there be any 7.x release with TypeScript 5.6 support, or will TypeScript 5.6+ require a typescript-eslint 8.x / eslint 9.x upgrade? (It's a non-trivial upgrade so we've been putting it off as long as possible.)

We don't backport changes, so yes you should upgrade, or stay on the older one if it happens to still work.

https://typescript-eslint.io/users/releases#back-porting-releases

We do not back port releases to previously released major/minor versions. We only ever release forward.

will TypeScript 5.6+ require a typescript-eslint 8.x / eslint 9.x upgrade?

Note that v8 of our tooling DOES NOT require v9 of eslint. You can use v8.57.0 of eslint just fine.

So you need only update to v8 of our tooling. That is a major bump, but it shouldn't be too painful. Source: I did it at my company with a monorepo of 80k TS files and it only took an hour or two.

The hardest part was updating code around changes to no-unused-vars but even then there was only a few dozen to update.

will TypeScript 5.6+ require a typescript-eslint 8.x / eslint 9.x upgrade?

Note that v8 of our tooling DOES NOT require v9 of eslint. You can use v8.57.0 of eslint just fine.

Does typescript-eslint officially support ESLint v8, or is it just by chance that it still works? Because https://typescript-eslint.io/users/dependency-versions seems to suggest that it only supports ESLint v9, so maybe that should be clarified if v8 is still supported.

I can add that I've been using the latest version of typescript-eslint with ESLint v8.57.0 as well for a while now, and I didn't notice any issue.

Note that v8 of our tooling DOES NOT require v9 of eslint. You can use v8.57.0 of eslint just fine.

As @guillaumebrunerie noted, this is contrary to https://typescript-eslint.io/users/dependency-versions/, which states:

The version range of ESLint currently supported is ^9.3.0.

This was what I was basing my comment on. If typescript-eslint actually still does support ESLint v8, that's great! The docs in that case should say ^8.57.0 || ^9.3.0 (or whatever the actual range is).

Will there be any 7.x release with TypeScript 5.6 support, or will TypeScript 5.6+ require a typescript-eslint 8.x / eslint 9.x upgrade? (It's a non-trivial upgrade so we've been putting it off as long as possible.)

One thing that you can consider is doing the upgrade but disabling the new rules added in the recommended configurations. This allows you to decouple the upgrade from the mass refactoring of turning on new lint rules. Upgrading to typescript-eslint v8 was not too much work in my company's mono-repo.

It's officially supported. The docs are wrong there. This was the enitre point of our v7 release - to bump the minimum eslint version to 8.56.0 so that we could easily support v8 and v9 of eslint.

The issue is that our docs are auto-generated via our root package.json version - so it's not truly correct and doesn't respect the real peer dependency.

Sorry if this question is stupid.

Is it works with arbitrary module identifiers?
https://devblogs.microsoft.com/typescript/announcing-typescript-5-6/#support-for-arbitrary-module-identifiers

I created unit test:

    ruleTester.run(`${ruleName}(${type}): works with arbitrary names`, rule, {
      valid: [
        {
          code: dedent`
            import { "🍎" as apple, "🍌" as banana } from 'module';
          `,
          options: [
            {
              ...options,
              specialCharacters: 'remove',
            },
          ],
        },
      ],
      invalid: [
        {
          code: dedent`
            import { "🍌" as banana, "🍎" as apple } from 'module';
          `,
          output: dedent`
            import { "🍎" as apple, "🍌" as banana } from 'module';
          `,
          options: [options],
          errors: [
            {
              messageId: 'unexpectedNamedImportsOrder',
              data: {
                left: 'banana',
                right: 'apple',
              },
            },
          ],
        },
      ],
    })

But it seems specifier.imported comes with Identifier type, not StringLiteral type.

Uh oh! @azat-io, the image you shared is missing helpful alt text. Check #9653 (comment).

Alt text is an invisible description that helps screen readers describe images to blind or low-vision users. If you are using markdown to display images, add your alt text inside the brackets of the markdown image.

Learn more about alt text at Basic writing and formatting syntax: images on GitHub Docs.

🤖 Beep boop! This comment was added automatically by github/accessibility-alt-text-bot.

But it seems specifier.imported comes with Identifier type, not StringLiteral type

@azat-io it comes with both

Your screenshot shows that because your first branch filters out Identifier?

@bradzacher Yes, but I've added the tests above.
And the line about the specified.imoprted StringLiteral type it doesn't cover. As if the type is always Identifier.

playground

I can see it working fine in the playground.

Sorry, thank you!

Btw, filed #10170 to fix the docs issue on what version of ESLint is supported.