{"id":2246,"date":"2019-06-24T08:29:25","date_gmt":"2019-06-24T16:29:25","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/typescript\/?p=2246"},"modified":"2019-06-24T08:29:25","modified_gmt":"2019-06-24T16:29:25","slug":"how-to-upgrade-to-typescript-without-anybody-noticing-part-2","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/typescript\/how-to-upgrade-to-typescript-without-anybody-noticing-part-2\/","title":{"rendered":"How to Upgrade to TypeScript without anybody noticing, Part 2"},"content":{"rendered":"

This guide will show you how to fix Typescript compile errors in Javascript project that recently added Typescript support via a\u00a0tsconfig.json<\/code>. It assumes that the\u00a0tsconfig.json<\/code>\u00a0is configured according to\u00a0the description in part 1 of this post<\/a>, and that you also installed types for some of your dependencies from the\u00a0@types\/*<\/code>\u00a0namespace. This guide is more of a list of tasks that you can pick and choose from, depending on what you want to fix first. Here are the tasks:<\/p>\n

    \n
  1. Add missing types in dependencies.<\/li>\n
  2. Fix references to types in dependencies.<\/li>\n
  3. Add missing types in your own code.<\/li>\n
  4. Work around missing types in dependencies.<\/li>\n
  5. Fix errors in existing types.<\/li>\n
  6. Add type annotations to everything else.<\/li>\n<\/ol>\n

    This guide does\u00a0not<\/em>\u00a0teach you how to write type definitions.\u00a0The Declaration section of the Typescript handbook<\/a>\u00a0is the best place to learn about that. Here, you’ll just see types presented without a lot of explanation.<\/p>\n

    <\/a>Add missing types in dependencies<\/h2>\n

    Let’s start with\u00a0@types\/shelljs<\/code>. In Makefile.js, I see a few errors. The first is that the module\u00a0require('shelljs\/make')<\/code>\u00a0isn’t found. The second group of errors is that the names ‘find’, ‘echo’ and a few others aren’t found.<\/p>\n

    These errors are related. It turns out that\u00a0@types\/shelljs<\/code>\u00a0doesn’t even include\u00a0shelljs\/make.d.ts<\/code>\u00a0right now. It’s completely missing. If you\u00a0look at the source<\/a>,\u00a0shelljs\/make.js<\/code>\u00a0does two things:<\/p>\n

      \n
    1. Add the contents of the parent shelljs to the global scope.<\/li>\n
    2. Add a global object named ‘target’ that allows you to add make targets.<\/li>\n<\/ol>\n

      Let’s say you want to add make to Definitely Typed so that it is available in\u00a0@types\/shelljs<\/code>. Your first step is to create\u00a0make.d.ts<\/code>\u00a0inside\u00a0node_modules\/@types\/shelljs\/<\/code>. This is the wrong location \u2014 it’s inside your own\u00a0node_modules<\/code> folder \u2014 but it makes development super easy to test that you’re actually adding the missing stuff. You can create a proper PR after everything is working.<\/p>\n

      Start with this:<\/p>\n

      \n
      import<\/span> *<\/span> as<\/span> shelljs<\/span> from<\/span> '<\/span>.\/'<\/span><\/span>;\r\ndeclare<\/span> global<\/span> {\r\n  const<\/span> cd:<\/span> typeof<\/span> shelljs<\/span>.cd<\/span>;\r\n  const<\/span> pwd:<\/span> typeof<\/span> shelljs<\/span>.pwd<\/span>;\r\n  \/\/ ... all the rest ...<\/span>\r\n}<\/pre>\n<\/div>\n
      This copies all of shelljs’ contents into the global namespace. Then add the type for\u00a0target<\/code>\u00a0to the globals as well:<\/p>\n
      \n
      const<\/span> target:<\/span> {\r\n  all?<\/span>:<\/span> Target<\/span>;\r\n  [s<\/span>:<\/span> string<\/span>]:<\/span> Target<\/span>;\r\n}\r\ninterface<\/span> Target<\/span> {\r\n  (...<\/span>args<\/span>:<\/span> any<\/span>[]):<\/span> void<\/span>;\r\n  result?<\/span>:<\/span> any<\/span>;\r\n  done?<\/span>:<\/span> boolean<\/span>;\r\n}<\/pre>\n<\/div>\n
      This exposes a couple more errors. See the section on fixing errors in existing types for how to fix those.<\/p>\n
      Now we want to publish this to Definitely Typed:<\/p>\n
        \n
      1. Fork\u00a0DefinitelyTyped<\/a>\u00a0on github.<\/li>\n
      2. git clone https:\/\/github.com\/your-name-here\/DefinitelyTyped<\/code><\/li>\n
      3. cp node_modules\/@types\/shelljs\/make.d.ts ~\/DefinitelyTyped\/types\/shelljs\/<\/code><\/li>\n
      4. git checkout -b add-shelljs-make<\/code><\/li>\n
      5. Commit the change and push it to your github fork.<\/li>\n
      6. Create a PR for the change.<\/li>\n<\/ol>\n
        If there are lint problems, the CI run on Definitely Typed will catch them.<\/p>\n
        For more detail on writing definitions for Definitely Typed,\u00a0see the Declaration section of the Typescript handbook<\/a>.<\/p>\n
        <\/a>Fix references to types in dependencies<\/h2>\n
        typescript-eslint-parser actually has quite a bit of type information in its source already. It just happens to be written in JSDoc, and it’s often almost, but not quite, what Typescript expects to see. For example, in\u00a0analyze-scope.js<\/code>,\u00a0visitPattern<\/code>\u00a0has an interesting mix of types:<\/p>\n
        \n
        \/**<\/span>\r\n * Override to use PatternVisitor we overrode.<\/span>\r\n * @param<\/span> {Identifier}<\/span> node<\/span> The Identifier node to visit.<\/span>\r\n * @param<\/span> {Object}<\/span> [options]<\/span> The flag to visit right-hand side nodes.<\/span>\r\n * @param<\/span> {Function}<\/span> callback<\/span> The callback function for left-hand side nodes.<\/span>\r\n * @returns<\/span> {void}<\/span><\/span>\r\n *\/<\/span>\r\nvisitPattern<\/span>(node<\/span>, options<\/span>, callback<\/span>) {\r\n    if<\/span> (!<\/span>node) {\r\n        return<\/span>;\r\n    }\r\n\r\n    if<\/span> (typeof<\/span> options ===<\/span> \"<\/span>function\"<\/span><\/span>) {\r\n        callback =<\/span> options;\r\n        options =<\/span> { processRightHandNodes:<\/span> false<\/span> };\r\n    }\r\n\r\n    const<\/span> visitor<\/span> =<\/span> new<\/span> PatternVisitor<\/span>(this<\/span>.options<\/span>, node, callback);\r\n    visitor<\/span>.visit<\/span>(node);\r\n\r\n    if<\/span> (options<\/span>.processRightHandNodes<\/span>) {\r\n        visitor<\/span>.rightHandNodes<\/span>.forEach<\/span>(this<\/span>.visit<\/span>, this<\/span>);\r\n    }\r\n}<\/pre>\n<\/div>\n
        In the JSDoc at the start, there’s an error on\u00a0Identifier<\/code>. (Object<\/code>\u00a0and\u00a0Function<\/code>\u00a0are fine, although you could write more specific types.) That’s weird, because those types\u00a0do<\/em>\u00a0exist in\u00a0estree<\/code>. The problem is that they’re not imported. Typescript lets you import types directly, like this:<\/p>\n
        \n
        import<\/span> { Identifier<\/span>, ClassDeclaration<\/span> } from<\/span> \"<\/span>estree\"<\/span><\/span>;<\/pre>\n<\/div>\n
        But this doesn’t work in Javascript because those are types, not values. Types don’t exist at runtime, so the import will fail at runtime when\u00a0Identifier<\/code>\u00a0is not found. Instead, you need to use an\u00a0import type<\/em>. An import type is just like a dynamic import, except that it’s used as a type. So, just like you could write:<\/p>\n
        \n
        const<\/span> estree<\/span> =<\/span> import<\/span>(\"<\/span>estree);<\/span><\/pre>\n<\/div>\n
        to dynamically import the\u00a0Identifier<\/code>\u00a0type from\u00a0estree<\/code>, you can write:<\/p>\n
        \n
        \/** @type<\/span> {import(\"estree\").Identifier <\/span>*\/<\/span>\r\nvar<\/span> id =<\/span> ...<\/span><\/pre>\n<\/div>\n
        to import the type\u00a0Identifier<\/code>\u00a0without an import statement. And, because it’s inconvenient to repeat\u00a0import<\/code>\u00a0all over the place, you usually want to write a\u00a0typedef<\/code>\u00a0at the top of the file:<\/p>\n
        \n
        \/** @typedef<\/span> {import(\"estree\").Identifier}<\/span> Identifier<\/span> *\/<\/span><\/pre>\n<\/div>\n
        With that alias in place, references to\u00a0Identifier<\/code>\u00a0resolve to the type from estree:<\/p>\n
        \n
        \/**<\/span>\r\n * @param<\/span> {Identifier}<\/span> node<\/span> now has the correct type<\/span>\r\n *\/<\/span><\/pre>\n<\/div>\n
        Here’s the commit.<\/a><\/p>\n
        <\/a>Add missing types in your own code<\/h2>\n
        Fixing these types still leaves a lot of undefined types in\u00a0analyze-scope.js<\/code>. The types\u00a0look<\/em>\u00a0like\u00a0estree<\/code>\u00a0types, but they’re prefixed with TS-, like\u00a0TSTypeAnnotation<\/code>\u00a0and\u00a0TSTypeQuery<\/code>. Here’s where\u00a0TSTypeQuery<\/code>\u00a0is used:<\/p>\n
        \n
        \/**<\/span>\r\n * Create reference objects for the object part. (This is `obj.prop`)<\/span>\r\n * @param<\/span> {TSTypeQuery}<\/span> node<\/span> The TSTypeQuery node to visit.<\/span>\r\n * @returns<\/span> {void}<\/span><\/span>\r\n *\/<\/span>\r\nTSQualifiedName<\/span>(node<\/span>) {\r\n    this<\/span>.visit<\/span>(node<\/span>.left<\/span>);\r\n}<\/pre>\n<\/div>\n
        It turns out that these types are specific to typescript-eslint-query. So you’ll have to define them yourself. To start, define the typedefs you need as\u00a0any<\/code>. This gets rid of the errors at the cost of accuracy:<\/p>\n
        \n
        \/** @typedef<\/span> {any}<\/span> TSTypeQuery<\/span> *\/<\/span>\r\n\/\/ lots more typedefs ...<\/span><\/pre>\n<\/div>\n
        At this point, you have two options: bottom-up discovery of how the types are used, or top-down documentation of what the types should be.<\/p>\n
        Bottom-up discovery, which is you’ll see below, has the advantage that you will end up with zero compile errors afterward. But it doesn’t scale well; when a type is used throughout a large project, the chances of it being\u00a0mis<\/em>used are pretty high.<\/p>\n
        Top-down documentation works well for large projects that already have some kind of documentation. You just need to know how to translate documentation into Typescript types;\u00a0the Declaration section of the Typescript handbook<\/a>\u00a0is a good starting point for this. You will sometimes have to change your code to fit the type using the top-down approach as well. Most of the time that’s because the code is questionable and needs to be changed, but sometimes the code is fine and the compiler gets confused and has to be placated.<\/p>\n
        Let’s use bottom-up discovery in this case because it looks like top-down documentation would involve copying the entire Typescript node API into\u00a0analyze-scope.js<\/code>. To do this, change the typedefs one by one to ‘unknown’, and look for errors that pop up. For example:<\/p>\n
        \n
        \/** @typedef<\/span> {unknown}<\/span> TSTypeQuery<\/span> *\/<\/span><\/pre>\n<\/div>\n
        Now there’s an error is on the usage of\u00a0TSTypeQuery<\/code>\u00a0in\u00a0TSQualifiedName<\/code>,\u00a0node.left<\/code>:<\/p>\n
        \n
        \/**<\/span>\r\n * Create reference objects for the object part. (This is `obj.prop`)<\/span>\r\n * @param<\/span> {TSTypeQuery}<\/span> node<\/span> The TSTypeQuery node to visit.<\/span>\r\n * @returns<\/span> {void}<\/span><\/span>\r\n *\/<\/span>\r\nTSQualifiedName<\/span>(node<\/span>) {\r\n    this<\/span>.visit<\/span>(node<\/span>.left<\/span>);\r\n    \/\/              ~~~~<\/span>\r\n    \/\/ error: type 'unknown' has no property 'left'<\/span>\r\n}<\/pre>\n<\/div>\n
        Looks like TSTypeQuery is supposed to have a\u00a0left<\/code>\u00a0property, so change\u00a0TSTypeQuery<\/code>\u00a0from\u00a0unknown<\/code>\u00a0to\u00a0{ left: unknown }<\/code>. There’s no more indication of what the type of\u00a0left<\/code>\u00a0is, so leave it as\u00a0unknown<\/code>:<\/p>\n
        \n
        \/** @typedef<\/span> {{ left: unknown }}<\/span> TSTypeQuery<\/span> *\/<\/span><\/pre>\n<\/div>\n
        As you can see, bottom-up type discovery can be a bit unsatisfying and underspecified, but it’s less disruptive to existing code.\u00a0Here’s the commit.<\/a><\/p>\n
        <\/a>Work around missing types<\/h2>\n
        Sometimes you’ll find that one of your dependencies has no\u00a0@types<\/code>\u00a0package at all. You are free to define types and contribute them to\u00a0Definitely Typed<\/a>, of course, but you usually need a quick way to work around missing dependencies. The easiest way is to add your own typings file to hold workarounds. Let’s look at\u00a0visitPattern<\/code>\u00a0in\u00a0analyze-scope.js<\/code> again:<\/p>\n
        \n
        \/**<\/span>\r\n * Override to use PatternVisitor we overrode.<\/span>\r\n * @param<\/span> {Identifier}<\/span> node<\/span> The Identifier node to visit.<\/span>\r\n * @param<\/span> {Object}<\/span> [options]<\/span> The flag to visit right-hand side nodes.<\/span>\r\n * @param<\/span> {Function}<\/span> callback<\/span> The callback function for left-hand side nodes.<\/span>\r\n * @returns<\/span> {void}<\/span><\/span>\r\n *\/<\/span>\r\nvisitPattern<\/span>(node<\/span>, options<\/span>, callback<\/span>) {\r\n    if<\/span> (!<\/span>node) {\r\n        return<\/span>;\r\n    }\r\n\r\n    if<\/span> (typeof<\/span> options ===<\/span> \"<\/span>function\"<\/span><\/span>) {\r\n        callback =<\/span> options;\r\n        options =<\/span> { processRightHandNodes:<\/span> false<\/span> };\r\n    }\r\n\r\n    const<\/span> visitor<\/span> =<\/span> new<\/span> PatternVisitor<\/span>(this<\/span>.options<\/span>, node, callback);\r\n    visitor<\/span>.visit<\/span>(node);\r\n\r\n    if<\/span> (options<\/span>.processRightHandNodes<\/span>) {\r\n        visitor<\/span>.rightHandNodes<\/span>.forEach<\/span>(this<\/span>.visit<\/span>, this<\/span>);\r\n    }\r\n}<\/pre>\n<\/div>\n
        Now there is an error on<\/p>\n
        \n
        const<\/span> visitor<\/span> =<\/span> new<\/span> PatternVisitor<\/span>(this<\/span>.options<\/span>, node, callback)\r\n                ~~~~~~~~~~~~~~~~~~<\/span>\r\n                Expected 0<\/span> arguments<\/span>, but got 3.<\/span><\/pre>\n<\/div>\n
        But if you look at\u00a0PatternVisitor<\/code>\u00a0in the same file<\/a>, it doesn’t even\u00a0have<\/em>\u00a0a constructor. But it does extend OriginalPatternVisitor<\/code>:<\/p>\n
        \n
        const<\/span> OriginalPatternVisitor<\/span> =<\/span> require<\/span>(\"<\/span>eslint-scope\/lib\/pattern-visitor\"<\/span><\/span>);\r\n\/\/ much later in the code...<\/span>\r\nclass<\/span> PatternVisitor<\/span> extends<\/span> OriginalPatternVisitor<\/span> {\r\n    \/\/ more code below ...<\/span>\r\n}<\/pre>\n<\/div>\n
        Probably\u00a0OriginalPatternVisitor<\/code>\u00a0has a 3-parameter constructor which\u00a0PatternVisitor<\/code>\u00a0inherits. Unfortunately,\u00a0eslint-scope<\/code>\u00a0doesn’t export\u00a0lib\/pattern-visitor<\/code>, so\u00a0PatternVisitor<\/code>\u00a0doesn’t\u00a0get<\/em>\u00a0the 3-parameter constructor. It ends up with a default 0-parameter constructor.<\/p>\n
        As described in “Add missing types in dependencies”, you could add\u00a0OriginalPatternVisitor<\/code>\u00a0in\u00a0lib\/pattern-visitor.d.ts<\/code>, just like we did for\u00a0make.d.ts<\/code>\u00a0in shelljs. But when you’re just getting started, sometimes you just want to put a temporary type in place. You can add the real thing later. Here’s what you can do:<\/p>\n
          \n
        1. Create\u00a0types.d.ts<\/code>\u00a0at the root of typescript-eslint-parser.<\/li>\n
        2. Add the following code:<\/li>\n<\/ol>\n
          \n
          declare<\/span> module<\/span> \"<\/span>eslint\/lib\/pattern-visitor\"<\/span><\/span> {\r\n    class<\/span> OriginalPatternVisitor<\/span> {\r\n        constructor<\/span>(x<\/span>:<\/span> any<\/span>, y<\/span>:<\/span> any<\/span>, z<\/span>:<\/span> any<\/span>) {\r\n        }\r\n    }\r\n    export<\/span> =<\/span> OriginalPatternVisitor<\/span>;\r\n}<\/pre>\n<\/div>\n
          This declares an “ambient module”, which is a pompous name for “fake workaround module”. It’s designed for exactly this case, though, where you are overwhelmed by the amount of work you need to do and just want a way to fake it for a while. You can even put multiple\u00a0declare module<\/code>s in a single file so that all your workarounds are in one place.<\/p>\n
          After this, you can improve the type of\u00a0OriginalPatternVisitor<\/code>\u00a0in the same bottom-up or top-down way that you would improve any other types. For example, you can look at\u00a0pattern-visitor.js<\/code>\u00a0in eslint<\/a>\u00a0to find the names of the constructor parameters. Then, a little lower in the\u00a0Identifier<\/code>\u00a0method of\u00a0OriginalPatternVisitor<\/code><\/a>\u00a0there is a usage of\u00a0callback<\/code> that gives enough information to guess its type.<\/p>\n
          Here’s what you’ll end up with<\/a>:<\/p>\n
          \n
          declare<\/span> module<\/span> \"<\/span>eslint-scope\/lib\/pattern-visitor\"<\/span><\/span> {\r\n    import<\/span> { Node<\/span> } from<\/span> \"<\/span>estree\"<\/span><\/span>;\r\n    type<\/span> Options<\/span> =<\/span> unknown<\/span>;\r\n    class<\/span> OriginalPatternVisitor<\/span> {\r\n        constructor<\/span>(\r\n            options<\/span>:<\/span> Options<\/span>,\r\n            rootPattern<\/span>:<\/span> Node<\/span>,\r\n            callback<\/span>:<\/span> (pattern<\/span>:<\/span> Node<\/span>, options<\/span>:<\/span> Options<\/span>) =><\/span> void<\/span>);\r\n    }\r\n    export<\/span> =<\/span> OriginalPatternVisitor<\/span>;\r\n}<\/pre>\n<\/div>\n
          <\/a>Fix errors in existing types<\/h2>\n
          Unfortunately, the improved type for pattern-visitor once again causes an error on\u00a0new PatternVisitor<\/code>. This time, the callback’s type,\u00a0Function<\/code>\u00a0isn’t specific enough to work with the specific function type of the callback:<\/p>\n
          \n
          callback<\/span>: (pattern<\/span>:<\/span> Node<\/span>, options<\/span>:<\/span> Options<\/span>) =><\/span> void<\/span><\/pre>\n<\/div>\n
          So the existing JSDoc type annotation needs to change:<\/p>\n
          \n
          \/**<\/span>\r\n * Override to use PatternVisitor we overrode.<\/span>\r\n * @param<\/span> {Identifier}<\/span> node<\/span> The Identifier node to visit.<\/span>\r\n * @param<\/span> {Object}<\/span> [options]<\/span> The flag to visit right-hand side nodes.<\/span>\r\n * @param<\/span> {Function}<\/span> callback<\/span> The callback function for left-hand side nodes.<\/span>\r\n * @returns<\/span> {void}<\/span><\/span>\r\n *\/<\/span>\r\nvisitPattern<\/span>(node<\/span>, options<\/span>, callback<\/span>) {<\/pre>\n<\/div>\n
          The right fix is to change the type\u00a0Function<\/code>\u00a0to the more precise\u00a0(pattern: Node, options: Options) => void<\/code>:<\/p>\n
          \n
          \/**<\/span>\r\n * Override to use PatternVisitor we overrode.<\/span>\r\n * @param<\/span> {Identifier}<\/span> node<\/span> The Identifier node to visit.<\/span>\r\n * @param<\/span> {Object}<\/span> [options]<\/span> The flag to visit right-hand side nodes.<\/span>\r\n * @param<\/span> {(pattern: Node, options: import(\"eslint-scope\/lib\/pattern-visitor\").Options) => void}<\/span> callback<\/span> The callback function for left-hand side nodes.<\/span>\r\n * @returns<\/span> {void}<\/span><\/span>\r\n *\/<\/span>\r\nvisitPattern<\/span>(node<\/span>, options<\/span>, callback<\/span>) {<\/pre>\n<\/div>\n
          <\/a>Add JSDoc types to everything else<\/h2>\n
          Once you get all the existing type annotations working, the next step is to add JSDoc types to everything else. You can turn on\u00a0\"strict\": true<\/code>\u00a0to see how far you have to go \u2014 among other things, this marks any variables that have the type\u00a0any<\/code>\u00a0with an error.<\/p>\n
          You should fall into a back-and-forth of adding new JSDoc type annotations and fixing old types. Usually old types just need to be updated to work with Typescript, but sometimes you’ll find a bug.<\/p>\n","protected":false},"excerpt":{"rendered":"
          This guide will show you how to fix Typescript compile errors in Javascript project that recently added Typescript support via a\u00a0tsconfig.json. It assumes that the\u00a0tsconfig.json\u00a0is configured according to\u00a0the description in part 1 of this post, and that you also installed types for some of your dependencies from the\u00a0@types\/*\u00a0namespace. This guide is more of a list […]<\/p>\n","protected":false},"author":1338,"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-2246","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-typescript"],"acf":[],"blog_post_summary":"
          This guide will show you how to fix Typescript compile errors in Javascript project that recently added Typescript support via a\u00a0tsconfig.json. It assumes that the\u00a0tsconfig.json\u00a0is configured according to\u00a0the description in part 1 of this post, and that you also installed types for some of your dependencies from the\u00a0@types\/*\u00a0namespace. This guide is more of a list […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/typescript\/wp-json\/wp\/v2\/posts\/2246","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\/1338"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/typescript\/wp-json\/wp\/v2\/comments?post=2246"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/typescript\/wp-json\/wp\/v2\/posts\/2246\/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=2246"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/typescript\/wp-json\/wp\/v2\/categories?post=2246"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/typescript\/wp-json\/wp\/v2\/tags?post=2246"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}