Today we are announcing the availability of TypeScript 5.7 Beta.<\/p>\n
To get started using the beta, you can get it through npm with the following command:<\/p>\n
npm install -D typescript@beta\r\n<\/code><\/pre>\nLet’s take a look at what’s new in TypeScript 5.7!<\/p>\n
Checks for Never-Initialized Variables<\/h2>\n
For a long time, TypeScript has been able to catch issues when a variable has not yet been initialized in all prior branches.<\/p>\n
let result: number\r\nif (someCondition()) {\r\n result = doSomeWork();\r\n}\r\nelse {\r\n let temporaryWork = doSomeWork();\r\n temporaryWork *= 2;\r\n \/\/ forgot to assign to 'result'\r\n}\r\n\r\nconsole.log(result); \/\/ error: Variable 'result' is used before being assigned.\r\n<\/code><\/pre>\nUnfortunately, there are some places where this analysis doesn’t work.\nFor example, if the variable is accessed in a separate function, the type system doesn’t know when the function will be called, and instead takes an "optimistic" view that the variable will be initialized.<\/p>\n
function foo() {\r\n let result: number\r\n if (someCondition()) {\r\n result = doSomeWork();\r\n }\r\n else {\r\n let temporaryWork = doSomeWork();\r\n temporaryWork *= 2;\r\n \/\/ forgot to assign to 'result'\r\n }\r\n\r\n printResult();\r\n\r\n function printResult() {\r\n console.log(result); \/\/ no error here.\r\n }\r\n}\r\n<\/code><\/pre>\nWhile TypeScript 5.7 is still lenient on variables that have possibly<\/em> been initialized, the type system is able to report errors when variables have never<\/em> been initialized at all.<\/p>\nfunction foo() {\r\n let result: number\r\n \r\n \/\/ do work, but forget to assign to 'result'\r\n\r\n function printResult() {\r\n console.log(result); \/\/ error: Variable 'result' is used before being assigned.\r\n }\r\n}\r\n<\/code><\/pre>\nThis change<\/a> was contributed thanks to the work of GitHub user Zzzen<\/a>!<\/p>\nPath Rewriting for Relative Paths<\/h2>\n
There are several tools and runtimes that allow you to run TypeScript code "in-place", meaning they do not require a build step which generates output JavaScript files.\nFor example, ts-node, tsx, Deno, and Bun all support running .ts<\/code> files directly.\nMore recently, Node.js has been investigating such support with --experimental-transform-types<\/code> and --experimental-strip-types<\/code>.\nThis is extremely convenient because it allows us to iterate faster without worrying about re-running a build task.<\/p>\nThere is some complexity to be aware of when using these modes though.\nTo be maximally compatible with all these tools, a TypeScript file that’s imported "in-place" must<\/strong> be imported with the appropriate TypeScript extension at runtime.\nFor example, to import a file called foo.ts<\/code>, we have to write the following in Node’s new experimental support:<\/p>\n\/\/ main.ts\r\n\r\nimport * as foo from ".\/foo.ts"; \/\/ <- we need foo.ts here, not foo.js\r\n<\/code><\/pre>\nTypically, TypeScript would issue an error if we did this, because it expects us to import the output file<\/em>.\nBecause some tools do allow .ts<\/code> imports, TypeScript has supported this import style with an option called --allowImportingTsExtensions<\/code> for a while now.\nThis works fine, but what happens if we need to actually generate .js<\/code> files out of these .ts<\/code> files?\nThis is a requirement for library authors who will need to be able to distribute just .js<\/code> files, but up until now TypeScript has avoided rewriting any paths.<\/p>\nTo support this scenario, we’ve added a new compiler option called --rewriteRelativeImportExtensions<\/code>.\nWhen an import path is relative<\/em> (starts with .\/<\/code> or ..\/<\/code>), ends in a TypeScript extension (.ts<\/code>, .tsx<\/code>, .mts<\/code>, .cts<\/code>), and is a non-declaration file, the compiler will rewrite the path to the corresponding JavaScript extension (.js<\/code>, .jsx<\/code>, .mjs<\/code>, .cjs<\/code>).<\/p>\n\/\/ Under --rewriteRelativeImportExtensions...\r\n\r\n\/\/ these will be rewritten.\r\nimport * as foo from ".\/foo.ts";\r\nimport * as bar from "..\/someFolder\/bar.mts";\r\n\r\n\/\/ these will NOT be rewritten in any way.\r\nimport * as a from ".\/foo";\r\nimport * as b from "some-package\/file.ts";\r\nimport * as c from "@some-scope\/some-package\/file.ts";\r\nimport * as d from "#\/file.ts";\r\nimport * as e from ".\/file.js";\r\n<\/code><\/pre>\nThis allows us to write TypeScript code that can be run in-place and then compiled into JavaScript when we’re ready.<\/p>\n
Now, we noted that TypeScript generally avoided rewriting paths.\nThere are several reasons for this, but the most obvious one is dynamic imports.\nIf a developer writes the following, it’s not trivial to handle the path that import<\/code> receives.\nIn fact, it’s impossible to override the behavior of import<\/code> within any dependencies.<\/p>\nfunction getPath() {\r\n if (Math.random() < 0.5) {\r\n return ".\/foo.ts";\r\n }\r\n else {\r\n return ".\/foo.js";\r\n }\r\n}\r\n\r\nlet myImport = await import(getPath());\r\n<\/code><\/pre>\nAnother issue is that (as we saw above) only relative<\/em> paths are rewritten, and they are written "naively".\nThis means that any path that relies on TypeScript’s baseUrl<\/code> and paths<\/code> will not get rewritten:<\/p>\n\/\/ tsconfig.json\r\n\r\n{\r\n "compilerOptions": {\r\n "module": "nodenext",\r\n \/\/ ...\r\n "paths": {\r\n "@\/*": [".\/src\/*"]\r\n }\r\n }\r\n}\r\n<\/code><\/pre>\n\/\/ Won't be transformed, won't work.\r\nimport * as utilities from "@\/utilities.ts";\r\n<\/code><\/pre>\nNor will any path that might resolve through the exports<\/code><\/a> and imports<\/code><\/a> fields of a package.json<\/code>.<\/p>\n\/\/ package.json\r\n{\r\n "name": "my-package",\r\n "imports": {\r\n "#root\/*": ".\/dist\/*"\r\n }\r\n}\r\n<\/code><\/pre>\n\/\/ Won't be transformed, won't work.\r\nimport * as utilities from "#root\/utilities.ts";\r\n<\/code><\/pre>\nAs a result, if you’ve been using a workspace-style layout with multiple packages referencing each other, you might need to use conditional exports<\/a> with scoped custom conditions<\/a> to make this work:<\/p>\n\/\/ my-package\/package.json\r\n\r\n{\r\n "name": "my-package",\r\n "exports": {\r\n ".": {\r\n "@my-package\/development": ".\/src\/index.ts",\r\n "import": ".\/lib\/index.js"\r\n },\r\n ".\/*": {\r\n "@my-package\/development": ".\/src\/*.ts",\r\n "import": ".\/lib\/*.js"\r\n }\r\n }\r\n}\r\n<\/code><\/pre>\nAny time you want to import the .ts<\/code> files, you can run it with node --conditions=@my-package\/development<\/code>.<\/p>\nNote the "namespace" or "scope" we used for the condition @my-package\/development<\/code>.\nThis is a bit of a makeshift solution to avoid conflicts from dependencies that might also use the development<\/code> condition.\nIf everyone ships a development<\/code> in their package, then resolution may try to resolve to a .ts<\/code> file which will not necessarily work.\nThis idea is similar to what’s described in Colin McDonnell’s essay Live types in a TypeScript monorepo<\/a><\/em>, along with tshy’s guidance for loading from source<\/a>.<\/p>\nFor more specifics on how this feature works, read up on the change here<\/a>.<\/p>\nSupport for --target es2024<\/code> and --lib es2024<\/code><\/h2>\nTypeScript 5.7 now supports --target es2024<\/code>, which allows users to target ECMAScript 2024 runtimes.\nThis target primarily enables specifying the new --lib es2024<\/code> which contains many features for SharedArrayBuffer<\/code> and ArrayBuffer<\/code>, Object.groupBy<\/code>, Map.groupBy<\/code>, Promise.withResolvers<\/code>, and more.\nIt also moves Atomics.waitAsync<\/code> from --lib es2022<\/code> to --lib es2024<\/code>.<\/p>\nNote that as part of the changes to SharedArrayBuffer<\/code> and ArrayBuffer<\/code>, the two now diverge a bit.\nTo bridge the gap and preserve the underlying buffer type, all TypedArrays<\/code> (like Uint8Array<\/code> and others) are now also generic<\/a>.<\/p>\ninterface Uint8Array<TArrayBuffer extends ArrayBufferLike = ArrayBufferLike> {\r\n \/\/ ...\r\n}\r\n<\/code><\/pre>\nEach TypedArray<\/code> now contains a type parameter named TArrayBuffer<\/code>, though that type parameter has a default type argument so that we can continue to refer to Int32Array<\/code> without explicitly writing out Int32Array<ArrayBufferLike><\/code>.<\/p>\nIf you encounter any issues as part of this update, you may need to update @types\/node<\/code>.<\/p>\nThis work<\/a> was primarily provided thanks to Kenta Moriuchi<\/a>!<\/p>\nSearching Ancestor Configuration Files for Project Ownership<\/h2>\n
When a TypeScript file is loaded in an editor using TSServer (like Visual Studio or VS Code), the editor will try to find the relevant tsconfig.json<\/code> file that "owns" the file.\nTo do this, it walks up the directory tree from the file being edited, looking for any file named tsconfig.json<\/code>.<\/p>\nPreviously, this search would stop at the first tsconfig.json<\/code> file found;\nhowever, imagine a project structure like the following:<\/p>\nproject\/\r\n\u251c\u2500\u2500 src\/\r\n\u2502 \u251c\u2500\u2500 foo.ts\r\n\u2502 \u251c\u2500\u2500 foo-test.ts\r\n\u2502 \u251c\u2500\u2500 tsconfig.json\r\n\u2502 \u2514\u2500\u2500 tsconfig.test.json\r\n\u2514\u2500\u2500 tsconfig.json\r\n<\/code><\/pre>\nHere, the idea is that src\/tsconfig.json<\/code> is the "main" configuration file for the project, and src\/tsconfig.test.json<\/code> is a configuration file for running tests.<\/p>\n\/\/ src\/tsconfig.json\r\n{\r\n "compilerOptions": {\r\n "outDir": "..\/dist"\r\n },\r\n "exclude": ["**\/*.test.ts"]\r\n}\r\n<\/code><\/pre>\n\/\/ src\/tsconfig.test.json\r\n{\r\n "compilerOptions": {\r\n "outDir": "..\/dist\/test"\r\n },\r\n "include": ["**\/*.test.ts"],\r\n "references": [\r\n { "path": ".\/tsconfig.json" }\r\n ]\r\n}\r\n<\/code><\/pre>\n\/\/ tsconfig.json\r\n{\r\n \/\/ This is a "workspace-style" or "solution-style" tsconfig.\r\n \/\/ Instead of specifying any files, it just references all the actual projects.\r\n "files": [],\r\n "references": [\r\n { "path": ".\/src\/tsconfig.json" },\r\n { "path": ".\/src\/tsconfig.test.json" },\r\n ]\r\n}\r\n<\/code><\/pre>\nThe problem here is that when editing foo-test.ts<\/code>, the editor would find project\/src\/tsconfig.json<\/code> as the "owning" configuration file – but that’s not the one we want!\nIf the walk stops at this point, that might not be desirable.\nThe only way to avoid this previously was to rename src\/tsconfig.json<\/code> to something like src\/tsconfig.src.json<\/code>, and then all files would hit the top-level tsconfig.json<\/code> which references every possible project.<\/p>\nproject\/\r\n\u251c\u2500\u2500 src\/\r\n\u2502 \u251c\u2500\u2500 foo.ts\r\n\u2502 \u251c\u2500\u2500 foo-test.ts\r\n\u2502 \u251c\u2500\u2500 tsconfig.src.json\r\n\u2502 \u2514\u2500\u2500 tsconfig.test.json\r\n\u2514\u2500\u2500 tsconfig.json\r\n<\/code><\/pre>\nInstead of forcing developers to do this, TypeScript 5.7 now continues walking up the directory tree to find other appropriate tsconfig.json<\/code> files for editor scenarios.\nThis can provide more flexibility in how projects are organized and how configuration files are structured.<\/p>\nYou can get more specifics on the implementation on GitHub here<\/a> and here<\/a>.<\/p>\nFaster Project Ownership Checks in Editors for Composite Projects<\/h2>\n
Imagine a large codebase with the following structure:<\/p>\n
packages\r\n\u251c\u2500\u2500 graphics\/\r\n\u2502 \u251c\u2500\u2500 tsconfig.json\r\n\u2502 \u2514\u2500\u2500 src\/\r\n\u2502 \u2514\u2500\u2500 ...\r\n\u251c\u2500\u2500 sound\/\r\n\u2502 \u251c\u2500\u2500 tsconfig.json\r\n\u2502 \u2514\u2500\u2500 src\/\r\n\u2502 \u2514\u2500\u2500 ...\r\n\u251c\u2500\u2500 networking\/\r\n\u2502 \u251c\u2500\u2500 tsconfig.json\r\n\u2502 \u2514\u2500\u2500 src\/\r\n\u2502 \u2514\u2500\u2500 ...\r\n\u251c\u2500\u2500 input\/\r\n\u2502 \u251c\u2500\u2500 tsconfig.json\r\n\u2502 \u2514\u2500\u2500 src\/\r\n\u2502 \u2514\u2500\u2500 ...\r\n\u2514\u2500\u2500 app\/\r\n \u251c\u2500\u2500 tsconfig.json\r\n \u251c\u2500\u2500 some-script.js\r\n \u2514\u2500\u2500 src\/\r\n \u2514\u2500\u2500 ...\r\n<\/code><\/pre>\nEach directory in packages<\/code> is a separate TypeScript project, and the app<\/code> directory is the main project that depends on all the other projects.<\/p>\n\/\/ app\/tsconfig.json\r\n{\r\n "compilerOptions": {\r\n \/\/ ...\r\n },\r\n "include": ["src"],\r\n "references": [\r\n { "path": "..\/graphics\/tsconfig.json" },\r\n { "path": "..\/sound\/tsconfig.json" },\r\n { "path": "..\/networking\/tsconfig.json" },\r\n { "path": "..\/input\/tsconfig.json" }\r\n ]\r\n}\r\n<\/code><\/pre>\nNow notice we have the file some-script.js<\/code> in the app<\/code> directory.\nWhen we open some-script.js<\/code> in the editor, the TypeScript language service (which also handles the editor experience for JavaScript files!) has to figure out which project the file belongs to so it can apply the right settings.<\/p>\nIn this case, the nearest tsconfig.json<\/code> does not<\/em> include some-script.js<\/code>, but TypeScript will proceed to ask "could one of the projects referenced<\/em> by app\/tsconfig.json<\/code> include some-script.js<\/code>?".\nTo do so, TypeScript would previously load up each project, one-by-one, and stop as soon as it found a project which contained some-script.js<\/code>.\nEven if some-script.js<\/code> isn’t included in the root set of files, TypeScript would still parse all the files within a project because some of the root set of files can still transitively<\/em> reference some-script.js<\/code>.<\/p>\nWhat we found over time was that this behavior caused extreme and unpredictable behavior in larger codebases.\nDevelopers would open up stray script files and find themselves waiting for their entire codebase to be opened up.<\/p>\n
Thankfully, every project that can be referenced by another (non-workspace) project must enable a flag called composite<\/code>, which enforces a rule that all input source files must be known up-front.\nSo when probing a composite<\/code> project, TypeScript 5.7 will only check if a file belongs to the root set of files<\/em> of that project.\nThis should avoid this common worst-case behavior.<\/p>\nFor more information, see the change here<\/a>.<\/p>\nValidated JSON Imports in --module nodenext<\/code><\/h3>\nWhen importing from a .json<\/code> file under --module nodenext<\/code>, TypeScript will now enforce certain rules to prevent runtime errors.<\/p>\nFor one, an import attribute containing type: "json"<\/code> needs to be present for any JSON file import.<\/p>\nimport myConfig from ".\/myConfig.json";\r\n\/\/ ~~~~~~~~~~~~~~~~~\r\n\/\/ \u274c error: Importing a JSON file into an ECMAScript module requires a 'type: "json"' import attribute when 'module' is set to 'NodeNext'.\r\n\r\nimport myConfig from ".\/myConfig.json" with { type: "json" };\r\n\/\/ ^^^^^^^^^^^^^^^^\r\n\/\/ \u2705 This is fine because we provided `type: "json"`\r\n<\/code><\/pre>\nOn top of this validation, TypeScript will not generate "named" exports, and the contents of a JSON import will only be accessible via a default.<\/p>\n
\/\/ \u2705 This is okay:\r\nimport myConfigA from ".\/myConfig.json" with { type: "json" };\r\nlet version = myConfigA.version;\r\n\r\n\/\/\/\/\/\/\/\/\/\/\/\r\n\r\nimport * as myConfigB from ".\/myConfig.json" with { type: "json" };\r\n\r\n\/\/ \u274c This is not:\r\nlet version = myConfig.version;\r\n\r\n\/\/ \u2705 This is okay:\r\nlet version = myConfig.default.version;\r\n<\/code><\/pre>\nSee here<\/a> for more information on this change.<\/p>\nSupport for V8 Compile Caching in Node.js<\/h2>\n
Node.js 22 supports a new API called module.enableCompileCache()<\/code><\/a>.\nThis API allows the runtime to reuse some of the parsing and compilation work done after the first run of a tool.<\/p>\nTypeScript 5.7 now leverages the API so that it can start doing useful work sooner.\nIn some of our own testing, we’ve witnessed about a 2.5x speed-up in running tsc --version<\/code>.<\/p>\nBenchmark 1: node .\/built\/local\/_tsc.js --version (*without* caching)\r\n Time (mean \u00b1 \u03c3): 122.2 ms \u00b1 1.5 ms [User: 101.7 ms, System: 13.0 ms]\r\n Range (min \u2026 max): 119.3 ms \u2026 132.3 ms 200 runs\r\n \r\nBenchmark 2: node .\/built\/local\/tsc.js --version (*with* caching)\r\n Time (mean \u00b1 \u03c3): 48.4 ms \u00b1 1.0 ms [User: 34.0 ms, System: 11.1 ms]\r\n Range (min \u2026 max): 45.7 ms \u2026 52.8 ms 200 runs\r\n \r\nSummary\r\n node .\/built\/local\/tsc.js --version ran\r\n 2.52 \u00b1 0.06 times faster than node .\/built\/local\/_tsc.js --version\r\n<\/code><\/pre>\nFor more information, see the pull request here<\/a>.<\/p>\nNotable Behavioral Changes<\/h2>\n
This section highlights a set of noteworthy changes that should be acknowledged and understood as part of any upgrade.\nSometimes it will highlight deprecations, removals, and new restrictions.\nIt can also contain bug fixes that are functionally improvements, but which can also affect an existing build by introducing new errors.<\/p>\n
lib.d.ts<\/code><\/h3>\nTypes generated for the DOM may have an impact on type-checking your codebase.\nFor more information, see linked issues related to DOM and lib.d.ts<\/code> updates for this version of TypeScript<\/a>.<\/p>\nTypedArray<\/code>s Are Now Generic Over ArrayBufferLike<\/code><\/h3>\nIn ECMAScript 2024, SharedArrayBuffer<\/code> and ArrayBuffer<\/code> have types that slightly diverge.\nTo bridge the gap and preserve the underlying buffer type, all TypedArrays<\/code> (like Uint8Array<\/code> and others) are now also generic<\/a>.<\/p>\ninterface Uint8Array<TArrayBuffer extends ArrayBufferLike = ArrayBufferLike> {\r\n \/\/ ...\r\n}\r\n<\/code><\/pre>\nEach TypedArray<\/code> now contains a type parameter named TArrayBuffer<\/code>, though that type parameter has a default type argument so that users can continue to refer to Int32Array<\/code> without explicitly writing out Int32Array<ArrayBufferLike><\/code>.<\/p>\nIf you encounter any issues as part of this update, such as<\/p>\n
error TS2322: Type 'Buffer' is not assignable to type 'Uint8Array<ArrayBufferLike>'.\r\nerror TS2345: Argument of type 'Buffer' is not assignable to parameter of type 'Uint8Array<ArrayBufferLike>'.\r\nerror TS2345: Argument of type 'ArrayBufferLike' is not assignable to parameter of type 'ArrayBuffer'.\r\nerror TS2345: Argument of type 'Buffer' is not assignable to parameter of type 'string | ArrayBufferView | Stream | Iterable<string | ArrayBufferView> | AsyncIterable<string | ArrayBufferView>'.\r\n<\/code><\/pre>\nthen you may need to update @types\/node<\/code>.<\/p>\nYou can read the specifics about this change on GitHub<\/a>.<\/p>\nCreating Index Signatures from Non-Literal Method Names in Classes<\/h3>\n
TypeScript now has a more consistent behavior for methods in classes when they are declared with non-literal computed property names.\nFor example, in the following:<\/p>\n
declare const symbolMethodName: symbol;\r\n\r\nexport class A {\r\n [symbolMethodName]() { return 1 };\r\n}\r\n<\/code><\/pre>\nPreviously TypeScript just viewed the class in a way like the following:<\/p>\n
export class A {\r\n}\r\n<\/code><\/pre>\nIn other words, from the type system’s perspective, [symbolMethodName]<\/code> contributed nothing to the type of A<\/code><\/p>\nTypeScript 5.7 now views the method [symbolMethodName]() {}<\/code> more meaningfully, and generates an index signature.\nAs a result, the code above is interpreted as something like the following code:<\/p>\nexport class A {\r\n [x: symbol]: () => number;\r\n}\r\n<\/code><\/pre>\nThis provides behavior that is consistent with properties and methods in object literals.<\/p>\n
Read up more on this change here<\/a>.<\/p>\nMore Implicit any<\/code> Errors on Functions Returning null<\/code> and undefined<\/code><\/h3>\nWhen a function expression is contextually typed by a signature returning a generic type, TypeScript now appropriately provides an implicit any<\/code> error under noImplicitAny<\/code>, but outside of strictNullChecks<\/code>.<\/p>\ndeclare var p: Promise<number>;\r\nconst p2 = p.catch(() => null);\r\n\/\/ ~~~~~~~~~~\r\n\/\/ error TS7011: Function expression, which lacks return-type annotation, implicitly has an 'any' return type.\r\n<\/code><\/pre>\nSee this change for more details<\/a>.<\/p>\nWhat’s Next?<\/h2>\n
At this point, TypeScript 5.7 is what we’d call "feature-stable".\nThe focus on TypeScript 5.7 will be bug fixes, polish, and certain low-risk editor features.\nWe’ll have a release candidate available in a bit over month, followed by a stable release soon after.\nIf you’re interested in planning around the release, be sure to keep an eye on our iteration plan<\/a> which has target release dates and more.<\/p>\nAs a note: while the beta is a great way to try out the next version of TypeScript, you can also try a nightly build<\/a> to get the most up-to-date version of TypeScript 5.7 up until our release candidate.\nOur nightlies are well-tested and can even be tested solely in your editor<\/a>.<\/p>\nSo please try out the beta or a nightly release today and let us know what you think!<\/p>\n
Happy Hacking!<\/p>\n
– Daniel Rosenwasser and the TypeScript Team<\/p>\n","protected":false},"excerpt":{"rendered":"
Today we are announcing the availability of TypeScript 5.7 Beta. To get started using the beta, you can get it through npm with the following command: npm install -D typescript@beta Let’s take a look at what’s new in TypeScript 5.7! Checks for Never-Initialized Variables For a long time, TypeScript has been able to catch issues […]<\/p>\n","protected":false},"author":381,"featured_media":1797,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[],"class_list":["post-4472","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-typescript"],"acf":[],"blog_post_summary":"
Today we are announcing the availability of TypeScript 5.7 Beta. To get started using the beta, you can get it through npm with the following command: npm install -D typescript@beta Let’s take a look at what’s new in TypeScript 5.7! Checks for Never-Initialized Variables For a long time, TypeScript has been able to catch issues […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/typescript\/wp-json\/wp\/v2\/posts\/4472","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/typescript\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/typescript\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/typescript\/wp-json\/wp\/v2\/users\/381"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/typescript\/wp-json\/wp\/v2\/comments?post=4472"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/typescript\/wp-json\/wp\/v2\/posts\/4472\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/typescript\/wp-json\/wp\/v2\/media\/1797"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/typescript\/wp-json\/wp\/v2\/media?parent=4472"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/typescript\/wp-json\/wp\/v2\/categories?post=4472"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/typescript\/wp-json\/wp\/v2\/tags?post=4472"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}