Add a rule to the compiler options to disallow the `assert` keyword for import attributes

[petamoriken]

🔍 Search Terms

"import assertions", "import attributes", "assert"

✅ Viability Checklist

• [X] This wouldn't be a breaking change in existing TypeScript/JavaScript code
• [X] This wouldn't change the runtime behavior of existing JavaScript code
• [X] This could be implemented without emitting different JS based on the types of the expressions
• [X] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• [X] This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
• [X] This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

⭐ Suggestion

Currently Stage 3 Import Attributes deprecates the assert keywords and is working to remove them from the spec if possible. V8 will remove support for the assert keywords, so Node.js and Chrome will follow suit.

Hey, quick update on this. Node.js is planning to remove support for assert in v22 (which will be released in April) and Chrome in v126 (which will be released in May).

https://github.com/denoland/deno/issues/17944#issuecomment-2027005952

I would like to remove support for the assert keywords from TypeScript as well, and would like to add disallowAssertKeywords to the compiler options as a beginning.

FYI

JSR bans publishing of TypeScript/JavaScript files that use the assert keywords. https://github.com/jsr-io/jsr/pull/427

I've made a PR for swc, but it is pending because I can't include features that are not in tsc. https://github.com/swc-project/swc/pull/8913

📃 Motivating Example

The following code will fail if the disallowAssertKeywords option is enabled.

import foo from "./foo.json" assert { type: "json" };

💻 Use Cases

1. What do you want to use this for?

Deno / JSR

2. What shortcomings exist with current approaches?

Deprecated the assert keywords cannot be rejected

3. What workarounds are you using in the meantime?

N/A

[RyanCavanaugh]

I think the most likely course of action is to deprecate the syntax in 6.0 with a compat flag for a little bit. A lint rule is probably the best choice if you need to ban this right away in some other scenario

[petamoriken]

I think the most likely course of action is to deprecate the syntax in 6.0 with a compat flag for a little bit.

👍

The DENO_FUTURE=1 environment variable disables the assert keywords in JavaScript, so I would like to gradually disable assert keywords in TypeScript as well by adding the disallowAssertKeywords option. https://github.com/denoland/deno/pull/23541

A lint rule is probably the best choice if you need to ban this right away in some other scenario

The no-import-assertions rule is already implemented in deno_lint and is enabled by default. https://github.com/denoland/deno_lint/pull/1209

[a-tarasyuk]

@RyanCavanaugh Should the disallowAssertKeywords option be added, or would this be considered an addition to the list of deprecated items?

[MartinJohns]

disallowAssertKeywords sounds super generic and can mistakenly interpreted to refer to asserts too. And "keywords" is pluralized, but I'm not sure to what other keyword this option refers to?

Perhaps something like disallowAssertImports would be better?

[a-tarasyuk]

The option name is open to discussion. However, it's more important to determine whether we need to add this new option or if this deprecation should be handled by the ignoreDeprecations option.

[RyanCavanaugh]

Sorry for the confusing metadata on this one. We think we'll just hold off on erroring until 6.0, at which point it'll become parsed-with-an-error, then just quit parsing at 6.5

[robpalme]

Thanks for the update. It's great that TS can evolve by retiring syntax as well as retiring flags.

Given that this leaves the hazard of TS emitting non-ideal (maybe even non-standard/non-executable) JS without any user guidance for the next 18 months, how would you feel about landing some mitigations earlier than 6.0? For example:

• Soft deprecation: assert does not error but does show a red squiggly + quick fix in the IDE
• Silent upgrade: Source TS using assert is emitted as with in the JS

[RyanCavanaugh]

I'd need to understand how someone would be unintentionally writing assert in an import statement to prioritize those mitigations

[robpalme]

Today Node LTS supports with and Node Latest does not support assert. In three weeks, Chrome will also not support assert.

• assert arrived in Chrome 92 (2021-07-20) & Node 17.5 (2022-02-10)
• with arrived in Chrome 123 (2024-03-19) & Node v18.20 (2024-03-06)
• assert was removed in Chrome 126 (2024-06-05) & Node 22.0 (2024-04-24)

So I think it's safe to say that anyone still using assert in the TS 5.6 time-frame (Sept 2024?) is doing so unintentionally. Either due to carry-over from existing code, or someone is following out of date documentation.

Both cases would benefit from TS guidance towards with. TC39 communications on this migration has limited reach, whereas TS can surface the forwards path readily.

[petamoriken]

In the TC39 meeting today we finally agreed to remove assert from the import attributes proposal.

https://x.com/nicoloribaudo/status/1818046677586153959