{"id":5473,"date":"2026-10-20T09:53:06","date_gmt":"2026-10-20T17:53:06","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/typescript\/?p=5473"},"modified":"2026-10-20T09:53:06","modified_gmt":"2026-10-20T17:53:06","slug":"announcing-typescript-7-1-beta","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/typescript\/announcing-typescript-7-1-beta\/","title":{"rendered":"Announcing TypeScript 7.1 Beta"},"content":{"rendered":"

Today we’re excited to announce the beta release of TypeScript 7.1!<\/p>\n

npm install -D typescript@beta\r\n<\/code><\/pre>\n
Let’s take a look at what’s new in TypeScript 7.1!<\/p>\n
Support for Import Attributes in Ambient Modules<\/h2>\n
Import attributes<\/a> are metadata that are attached to import statements.\nTypically, they’re meant to instruct runtimes and bundlers on how to interpret the content of an import, as well as the shape of the resulting module.\nFor example,<\/p>\n
import myData from \".\/data\/someData.json\" with { type: \"json\" };\r\n<\/code><\/pre>\n
Everything in the object following the with<\/code> keyword is an import attribute.\nEnvironments like browsers can’t simply decide how to deal with an import based on file name extensions like .json<\/code>.\nSpecifying type: \"json\"<\/code> tells whatever runtime that someData.json<\/code> needs to be interpreted as a JSON file, parsed out, and provided via a default import (in our example above, that’s myData<\/code>).<\/p>\n
The type<\/code> attribute has become the de facto way for runtimes to customize this behavior.\nECMAScript (JavaScript) has a proposal<\/a> that allows code to specify type: \"text\"<\/code>, which returns the import’s contents as a string.<\/p>\n
import readme from \"..\/README.md\" with { type: \"text\" };\r\n\r\nconsole.log(readme);\r\n<\/code><\/pre>\n
There is also a proposal<\/a> for type: \"bytes\"<\/code> to return a Uint8Array<\/code> of raw bytes.<\/p>\n
import { pngToPixels, boxBlur } from \".\/photoUtils.js\";\r\n\r\nimport photo from \".\/myPhoto.png\" with { type: \"bytes\" };\r\nconst blurryPhoto = boxBlur(pngToPixels(photo));\r\n<\/code><\/pre>\n
Browsers have also allowed importing CSS files as CSSStyleSheet<\/code>s with type: \"css\"<\/code> for a few years now.<\/p>\n
import someTheme from \".\/themes\/someCoolTheme.css\" with { type: \"css\" };\r\n\r\ndocument.adoptedStyleSheets.push(someTheme);\r\n<\/code><\/pre>\n
To support importing these files, people might use ambient module declarations<\/em> in TypeScript using a wildcard pattern (e.g. *.css<\/code>).<\/p>\n
\/\/ You can write this in a global `.d.ts` file with no import statements.\r\n\r\ndeclare module \"*.css\" {\r\n    const content: CSSStyleSheet;\r\n    export default content;\r\n}\r\n\r\ndeclare module \"*.txt\" {\r\n    const content: string;\r\n    export default content;\r\n}\r\n\r\ndeclare module \"*.md\" {\r\n    const content: string;\r\n    export default content;\r\n}\r\n\r\ndeclare module \"*.bin\" {\r\n    const content: Uint8Array;\r\n    export default content;\r\n}\r\n<\/code><\/pre>\n
This is okay, but it doesn’t work for all environments as it doesn’t account for import attributes at all.<\/p>\n
You might ask why this is an issue – at first glance, it seems like the only problem is that it just allows people to accidentally leave off an import attribute.<\/p>\n
\/\/ \u274c oops, forgot an import attribute\r\nimport readme from \"..\/README.md\";\r\n\r\n\/\/ \u2705 what we were supposed to write\r\nimport readme from \"..\/README.md\" with { type: \"text\" };\r\n<\/code><\/pre>\n
But that is still a problem worth fixing.\nAnother issue is that it becomes repetitive.\nWith import attributes, the entire issue is that the runtime cares about the attributes, not the file extension.\nWe shouldn’t have to re-declare a pattern for both .txt<\/code> and .md<\/code> files if both were going to use type: \"text\"<\/code>.<\/p>\n
But a major issue is that runtime environments may support different import attributes entirely, and may act differently depending on whether they’re present.\nFor example, bundlers might use a build-time feature called CSS Modules<\/a> as the default behavior when importing .css<\/code> files, but specifying the browser-supported type: \"css\"<\/code> in the import statement will override this behavior and ensure the .css<\/code> file is brought in as a CSSStyleSheet<\/code> object.<\/p>\n
That’s why TypeScript 7.1 introduces support for import attributes in ambient module declarations.\nYou can now declare the following in your TypeScript projects, get an error if you try to import a file without the required import attributes, and get the correct type based on the import attributes.<\/p>\n
declare module \"*\" with { type: \"css\" } {\r\n    const content: CSSStyleSheet;\r\n    export default content;\r\n}\r\n\r\ndeclare module \"*\" with { type: \"text\" } {\r\n    const content: string;\r\n    export default content;\r\n}\r\n\r\ndeclare module \"*\" with { type: \"bytes\" } {\r\n    const content: Uint8Array;\r\n    export default content;\r\n}\r\n<\/code><\/pre>\n
Note that imports matching these declarations are not validated against files on disk.\nAs is currently the behavior when an import matches an ambient module declaration, failed lookups will be reported at runtime or during a bundler’s build process.<\/p>\n
Also note that these declarations are not shipped as part of the TypeScript built-in libraries.\nWe recommend libraries not<\/strong> include them in their published packages, and end-users will need to declare them in their own projects if necessary.\nThat will provide end-users with flexibility on how the global scope is configured (e.g. lib.dom.d.ts<\/code> versus @types\/node<\/code>) and will prevent conflicts with built-in declarations in the future.<\/p>\n
For more information, see our implementing pull request here<\/a>.<\/p>\n
Source Phase Imports<\/h2>\n
Source phase imports<\/a> are a proposed new feature in ECMAScript<\/a>.\nThe feature introduces a new source<\/code> modifier\/keyword that follows the import<\/code> keyword.\nOnly default imports can be written with import source<\/code>.<\/p>\n
import source SomeModule from \"some-module\";\r\n<\/code><\/pre>\n
The idea with this feature is that when we use import source<\/code>, we’ll get back an object that represents the module after it’s been parsed and analyzed by the runtime, but before<\/em> its imports have been loaded (and therefore, before they have been validated or linked against other modules, and before any code contained in the module can run).\nThis object on its own is kind of “inert” – it’s an instance of something called an AbstractModuleSource<\/code> which is eventually<\/em> meant to be imported or instantiated.<\/p>\n
For WebAssembly (wasm) imports, that object will be an instance of a WebAssembly.Module<\/code>.\nWhat’s useful with these objects is that they can be passed directly into WebAssembly.instantiate<\/code>.<\/p>\n
import source SuperFastThing from \".\/super-fast-thing.wasm\";\r\nimport { WASI } from \"node:wasi\";\r\n\r\nconst wasi = new WASI({ \/*...*\/ });\r\nconst fastThingInstance = await WebAssembly.instantiate(SuperFastThing, {\r\n    wasi_snapshot_preview1: wasi.wasiImport\r\n});\r\n\r\nwasi.start(fastThingInstance);\r\n<\/code><\/pre>\n
WebAssembly source imports are already supported in recent versions of Node.js<\/a>.<\/p>\n
At the moment, you can’t do much with a source import of a JavaScript file.\nThe spirit of the proposal implies at some point we might be able to pass a JavaScript module source directly into an import()<\/code> call.<\/p>\n
import source SomeModule from \".\/someModule.js\";\r\nconst moduleInstance = await import(SomeModule);\r\n<\/code><\/pre>\n
Another part of the idea with JavaScript source imports is that, over time, we may gain other features that will allow us to be able to customize behavior around how modules are loaded and instantiated, similar to how we did with WebAssembly.instantiate<\/code> above.\nBut we’re not there yet, and in fact, many environments and tools still don’t currently support JavaScript source imports in the first place.<\/p>\n
Source imports aren’t limited to import statements though.\nYou can also perform a dynamic<\/em> source import as well via the import.source<\/code> meta-property function.<\/p>\n
const SuperFastThing = await import.source(\".\/super-fast-thing.wasm\");\r\nconst fastThingInstance = await WebAssembly.instantiate(SuperFastThing, {\r\n    \/\/ ...\r\n});\r\n<\/code><\/pre>\n
Source imports retain identity.\nThat means you can use them in Map<\/code>s and Set<\/code>s, or compare against them reliably.<\/p>\n
\/\/ Note that `WebAssembly.instantiate` always returns a distinct object.\r\nimport source source1 from \".\/plugin.wasm\"\r\nimport source source2 from \".\/plugin.wasm\"\r\nconst source3 = await import.source(\".\/plugin.wasm\");\r\n\r\nconsole.log(source1 === source2); \/\/ true\r\nconsole.log(source2 === source3); \/\/ true\r\n<\/code><\/pre>\n
When using import source<\/code>, every imported module has the type AbstractModuleSource<\/code>, a new global type in lib.esnext.d.ts<\/code>.\nYou must have an appropriate --module<\/code> setting (i.e. esnext<\/code>, nodenext<\/code>, or preserve<\/code>) to use source imports, as well as the appropriate esnext<\/code> option in --lib<\/code> or --target<\/code>.<\/p>\n
This feature was implemented<\/a> thanks to the work of Oleksandr Tarasiuk<\/a>.<\/p>\n
--target es2026<\/code><\/h2>\n
TypeScript 7.1 now supports es2026<\/code> as a stable --target<\/code> and --lib<\/code> option.\nOnly lib<\/code> additions are significant, as declarations have been added, or moved from esnext<\/code> as proposed features have stabilized in ECMAScript 2026.<\/p>\n
Stabilizations in --lib es2026<\/code> include:<\/p>\n