TypeScript 7.1 Beta: ambient modules can finally declare import attributes, and --target reaches es2026
The beta has six sections: import attributes in ambient modules, source phase imports, --target es2026, new library methods, the 7.1 API (snapshots, file system, content mappers) and a few behavioral changes.
TypeScript 7.1 Beta landed on October 20; npm install -D typescript@beta gets you in. It is the first feature release after 7.0, and the announcement has six sections. I reordered them by “will this affect my project”.
Import attributes in ambient modules
The headline. Import attributes are metadata attached to an import statement:
import myData from "./data/someData.json" with { type: "json" };
import readme from "../README.md" with { type: "text" };
import photo from "./myPhoto.png" with { type: "bytes" };
Browsers and runtimes cannot guess how to treat an import from the extension alone, so type became the de facto standard: json parses JSON, text returns a string, bytes returns a Uint8Array, css returns a CSSStyleSheet you can push into document.adoptedStyleSheets.
The problem was on the declaration side. To support import "./x.css" you wrote a wildcard ambient declaration:
// before: you could declare the module shape, not which attributes make it legal
declare module "*.css";
7.1 lets ambient module declarations carry attribute constraints, so “*.css must be imported with type: "css"” becomes expressible. This matters more for library authors: previously the type layer could not reject a wrong with clause.

Source phase imports and –target es2026
import source x from "./mod.wasm" — take a module’s source without instantiating it — is in the beta. It is for passing modules around as resources, to a Worker or to WebAssembly.compile.
--target es2026 pushes the output language level to next year’s edition. My rule: target should follow your runtime, not the calendar. On Node 26 or Chrome 156, es2026 is fine; if you still support older browsers, the extra downleveling makes output messier.

The 7.1 API: three pieces
This section is for tool authors, and it is the most substantive part of 7.1:
- Snapshots: a consistent view of compiler state without rerunning full analysis — what language services need.
- File System APIs: file access abstracted behind a replaceable implementation, so in-memory, virtual or remote file systems can plug in.
- Content Mappers: a layer that decouples “the source file” from “the content the compiler sees” — for injecting virtual files or rewriting content.
Together they point at one thing: making TypeScript easier to embed in other tools. Before, building a custom language service on top meant forking or patching; now there are official interfaces.
Two behavioral changes
- lib.d.ts adjustments: touching lib can make previously compiling code fail. Run
tsc --noEmitbefore upgrading. - Stronger checks on distributive type parameters: conditional types now check them harder. This kind of tightening usually surfaces as a batch of new errors in generic utility libraries, reported far from the actual mistake.

Try it or not
My advice: try it on your own libraries and tools; keep production apps on stable. The reasoning is concrete — 7.1’s value concentrates in the API section, and the consumers of that API are tool authors. Normal projects get --target es2026 and new library methods, which is a small win, while lib.d.ts and the stricter checks cost real fixing time.
If you do try it, do one thing first: diff tsc --noEmit output against 7.0 item by item. The blast radius of behavioral changes can only be measured, not inferred from release notes.

Comments
…