{"id":2530,"date":"2022-05-07T22:55:26","date_gmt":"2022-05-08T02:55:26","guid":{"rendered":"https:\/\/www.alpharithms.com\/?p=2530"},"modified":"2022-05-27T17:59:31","modified_gmt":"2022-05-27T21:59:31","slug":"configuring-typescript-in-webstorm","status":"publish","type":"post","link":"https:\/\/www.alpharithms.com\/configuring-typescript-in-webstorm-265522\/","title":{"rendered":"Configuring Typescript in Webstorm"},"content":{"rendered":"

Typescript is a powerful language that provides javascript developers a means to add static typing, enums, interfaces, and other features of common software development languages like C# or Java.<\/p>\n

Webstorm is Jetbrains’ dedicated web-language IDE geared to specifically support languages like HTML, CSS, SASS\/SCSS, and Javascript. Webstorm offers native support for Typescript but a little added configuration goes far.<\/p>\n

In this article, we’ll walk through the steps to configure a basic TypeScript project in Webstorm that will transpile to a single JavaScript file suitable for browser-based applications.<\/p>\n

Quick Intro: Typescript 101<\/h2>\n

The clich\u00e9 way of introducing TypeScript is “as a superset of JavaScript” which isn’t really descriptive as to\u00a0why<\/em> one would want to use it. It can also be described as\u00a0sensibility for JavaScript<\/em> in that it allows developers to use common software constructs within an otherwise casual language. Enums, Static typing, and disabling implicit type coercions are a few of the features TypeScript offers.<\/p>\n

Back to the “Superset of JavaScript” description — while clich\u00e9, it’s important to understand. This characteristic means that all JavaScript code is valid TypeScript code<\/strong> — at least\u00a0syntactically<\/em>. There are, however, many cases where the TypeScript compiler may be unhappy.\u00a0 TypeScript also compiles to run anywhere JavaScript will run<\/strong>. We’ll glaze past the rest of the history for now and get to configuring TypeScript with Webstorm.<\/p>\n

Assumptions<\/h2>\n

This article makes several assumptions about programming environments, available software, and pre-existing familiarity. These are as follows:<\/p>\n

    \n
  1. Node.js is installed (see here<\/a>)<\/li>\n
  2. npm is installed (see here<\/a>)<\/li>\n
  3. Webstorm is installed (see here<\/a>)<\/li>\n
  4. An empty node.js project ($ npm init<\/code>)<\/li>\n
  5. A working internet connection (????)<\/li>\n<\/ol>\n

    Regarding assumption #2, npm is the package manager for Node.js and is now a part of the standard Node.js installation. If Node.js is installed, npm install\/version can be confirmed by running npm -version<\/code>. The latest version can always be obtained via npm install npm@latest -g<\/code> in the console. The -g<\/code> flag — meaning “global” instructs the install to update the global Node.js npm version vs. a local environment.<\/p>\n

    Step 1: Install ts-node<\/h2>\n

    Webstorm comes with native TypeScript support but we’ll be taking things a step further. Here we will install the ts-node package<\/a> via npm which provides a range of functionality for TypeScript projects in a local environment. At this point we have a bare-bones Node.js project, with a package.json file as follows:<\/p>\n

    {\r\n  \"name\": \"typescript-ws-config\",\r\n  \"version\": \"1.0.0\",\r\n  \"description\": \"Just configuring typescript with Webstorm\",\r\n  \"main\": \"index.js\",\r\n  \"author\": \"Zack West <alphazwest@gmail.com>\",\r\n  \"license\": \"MIT\"\r\n}<\/pre>\n
    Install ts-node with the following command: npm install ts-node --save-dev<\/code>. This can be done via the native OS terminal or via the integrated terminal window in the Webstorm IDE as shown below:<\/p>\n
    \"typescript<\/a>
    npm commands can be run via the terminal natively or via the integrated Webstorm terminal.<\/figcaption><\/figure>\n
    The --save-dev<\/code> flag adds ts-node as a dependency within the devDependencies section in our package.json file. This indicates that ts-node<\/code> should not be installed when the production flag is passed with the install command such as: npm ts-node --production<\/code>. This allows those using a package only for its end-use to avoid unnecessary dependencies. As a rule: if the application can run without the dependency then it should be a development dependency.<\/p>\n
    Step 2: Create a tsconfig.json file.<\/h2>\n
    Webstorm has native TypeScript support that is enabled when a tsconfig.json<\/code> file is created — indicating the project root of a TypeScript project. This will signal to Webstorm the presence of a TypeScript project and auto-configure a TypeScript compiler (transpiler.)<\/p>\n
    Creating the tsconfig.json<\/code> file can be done manually or via Webstorm by right-clicking on the project directory icon, and selecting new<\/em> > tsconfig.json file.<\/em> This approach with auto-populates the file with the following options:<\/p>\n
    {\r\n  \"compilerOptions\": {\r\n    \"module\": \"commonjs\",\r\n    \"target\": \"es6\",\r\n    \"sourceMap\": true\r\n  },\r\n  \"exclude\": [\r\n    \"node_modules\"\r\n  ]\r\n}<\/pre>\n
    This article won’t go into depth regarding possible options in the tsconfig.json file. For more on that, check out the official documentation<\/a>. We will adjust a few options in a moment but for now, we’ll focus on a bare-bones project structure and project settings.<\/p>\n
    Step 3: Configure Ts-Node Support<\/h2>\n
    Webstorm comes with a bundled TypeScript package that will be used by default once a tsconfig.json file is detected. However, we’re using a local version (installed with ts-node) for greater flexibility. The main advantage is that our project won’t rely<\/em> on Webstorm — even though we’re using it. In addition to including the typescript package itself, ts-node offers some added features\/benefits:<\/p>\n
      \n
    1. Read-eval-print Loop (REPL) for continuous transcompilation<\/li>\n
    2. Type checking<\/li>\n
    3. Integrates with test-runners<\/li>\n
    4. Automatic sourcemaps in stack traces<\/li>\n
    5. Automatic tsconfig.json parsing<\/li>\n<\/ol>\n
      These features, among others, help justify the desire to extend the native support for TypeScript in Webstorm. To ensure ts-node is used fully, we need to configure Webstorm to use the local typescript package in the node_modules directory of our project. This is done by selecting the local package in the TypeScript configuration menu in Webstorm located in Settings > Languages and Frameworks > TypeScript<\/em>:<\/p>\n
      \"typescript<\/a>
      Webstorm should automatically detect the local typescript version that is, in all likelihood, a newer version compared to the one bundled with Webstorm.<\/figcaption><\/figure>\n
      Optionally, the “Recompile on changes” option can be enabled to — as the name implies — ensure that all .ts<\/code> or .tsx<\/code> files are recompiled into .js<\/code> files when changes are detected. Click Apply<\/strong> and then Ok to exit while saving changes.<\/p>\n
      Step 3: Configure TSConfig.json<\/h2>\n
      Our current tsconfig.json<\/code> file does little more than indicate that our project is configured for TypeScript. We’ll specify some options to help harness some useful features of Node.js, the typescript module, and ts-node. Note that Webstorm code-completion suggestions will now be available for TypeScript-native features including tsconfig.json<\/code> options and values:<\/p>\n
      \"typescript<\/a>
      Webstorm code completion will provide a list of suggestions for tsconfig options and values.<\/figcaption><\/figure>\n
      Below is a list and a brief description of the options we will be adding, their values, and the motivation for doing so:<\/p>\n
        \n
      1. module: umd<\/strong> – specifies a project to be loaded as a module in a module-supporting environment or, if module use is not supported, to be loaded as a global. (read here<\/a>)<\/li>\n
      2. noImplicitAny: true<\/strong> – Instructs the typescript compiler to enforce strict typing such that any types are not allowed as fallbacks (read here<\/a>)<\/li>\n
      3. strictNullChecks: true<\/strong> – Instructs the compiler to make sure objects are checked for values of null or undefined. (read here<\/a>)<\/li>\n
      4. moduleResolution: node<\/strong> – TypeScript recommends commonjs<\/code> as a value here but we’re using node<\/code> for deep node.js support.<\/li>\n<\/ol>\n
        The tsconfig.json<\/code> file allows for great complexity if one chooses or if a project dictates the need. The updated version of our tsconfig.json file is as follows:<\/p>\n
        {\r\n  \"compilerOptions\": {\r\n    \"module\": \"commonjs\",\r\n    \"target\": \"es6\",\r\n    \"sourceMap\": true,\r\n    \"noImplicitAny\": true,\r\n    \"moduleResolution\": \"node\",\r\n  },\r\n  \"exclude\": [\r\n    \"node_modules\"\r\n  ]\r\n}<\/pre>\n
        This is good for now, though in the next steps we’ll be adding some extra options based on our project’s structure.<\/p>\n
        Step 4: Project Structure & Files<\/h2>\n
        Our project is bare-bones currently and needs some basic structure to demonstrate what the TypeScript transpiler does and how it does it. We’ll be adding two sub-directories to our project: src<\/code> and dist<\/code> and an index.ts file in the src directory. The project structure now reflects the following:<\/p>\n
        .\r\n\u2514\u2500\u2500\u00a0WebstormTypescript\/\r\n\u00a0\u00a0\u00a0\u00a0\u251c\u2500\u2500\u00a0node_modules\r\n\u00a0\u00a0\u00a0\u00a0\u251c\u2500\u2500\u00a0dist\r\n\u00a0\u00a0\u00a0\u00a0\u251c\u2500\u2500\u00a0src\/\r\n\u00a0\u00a0\u00a0\u00a0\u2502\u00a0\u00a0\u00a0\u2514\u2500\u2500\u00a0index.ts\r\n\u00a0\u00a0\u00a0\u00a0\u251c\u2500\u2500\u00a0package.json\r\n\u00a0\u00a0\u00a0\u00a0\u251c\u2500\u2500\u00a0package-lock.json\r\n\u00a0\u00a0\u00a0\u00a0\u2514\u2500\u2500\u00a0tsconfig.json<\/pre>\n
        Unless something has gone wrong, ts-node’s REPL service will create a compiled version of index.ts<\/code> along with a index.js.map<\/code> file which will appear in the src<\/code> directory alongside the index.ts<\/code> file\u2014which should all be degrees of blank varying from completely<\/em> blank to functionally<\/em> blank. This confirms that ts-node, typescript, and Webstorm are all playing nicely, but also raises some questions about the need for the dist<\/code> directory. Let us now revisit the tsconfig.json<\/code> file and configure a more controlled emission of compiled .ts<\/code> files.<\/p>\n
        Step 5: Configure Emission Options<\/h2>\n
        Emission options \u2014 a.k.a. compiler output options \u2014 instruct the typescript compiler on how to handle .ts files and the resulting .js files. Specifically, our concern will be focused on the two following areas:<\/p>\n
          \n
        1. Which .ts<\/code> files will be compiled<\/li>\n
        2. Where the compiled .js<\/code> files will be emitted<\/li>\n<\/ol>\n
          These concerns can be addressed via the outDir<\/code> and include<\/span><\/span>\u00a0options in the tsconfig.json<\/code> file. The first is added within the compilerOptions<\/code> group and the latter is a separate top-level group.<\/p>\n
          Via each of these options, we’ll specify values that instruct the typescript compiler to recursively compile all .ts<\/code> files in the src<\/code> directory and emmit those files in\u00a0the dist<\/code> directory. Our tsconfig.json<\/code> file will be updated as follows:<\/p>\n
          {\r\n  \"compilerOptions\": {\r\n    \"module\": \"commonjs\",        \/\/ default\r\n    \"target\": \"es6\",\r\n    \"sourceMap\": true,\r\n    \"noImplicitAny\": true,\r\n    \"moduleResolution\": \"node\",  \/\/ default\r\n    \"outDir\": \"dist\",\r\n  },\r\n  \"include\": [\r\n    \"src\/**\/*\"\r\n  ],\r\n  \"exclude\": [\r\n    \"node_modules\"\r\n  ]\r\n}\r\n<\/pre>\n
          Note the inclusion of the module<\/code> and moduleResolution<\/code> options here. The values commonjs<\/code> and node<\/code> are defaults unless otherwise specified and included here for the sake of being explicit only.<\/p>\n
          At this point, we are ready to take TypeScript’s compiler for a whirl and see where we end up. Before we do that however, there are some important points to note:<\/p>\n
            \n
          1. TypeScript’s compiler allows all files to compile down to a single file, specified via a \"outFile\"<\/code> option in the compilerOptions<\/code> group in the tsconfig.json<\/code> file. However, this can only be done if the \"module\"<\/code> value is set to \"amd\"<\/code> or \"system.\"<\/code> .<\/li>\n
          2. As it stands, our files will all be compiled as separate files, including any sub-directory hierarchy that might be present in the src<\/code> directory.<\/li>\n
          3. A tool like webpack<\/code> can be used to combine all files during compilation but is beyond the scope of this article. See here for info<\/a>.<\/li>\n<\/ol>\n
            Step 6: Adding Sample Code<\/h2>\n
            Compiling blank files is both boring and not illustrative of TypeScript, the typescript compiler, or the resulting JavaScript. The following three files and content are being added to demonstrate how all this actually works — albeit in a very contrived example.<\/p>\n
            src\/index.ts<\/h3>\n
            import {broadcast} from \".\/utils\/helpers\";\r\nimport {Greeting} from \".\/enums\/greetings\";\r\n\r\n\/\/ Print a hello message to the console\r\nfor (const value in Greeting){\r\n    broadcast(`${value.toLowerCase()}, world!`);\r\n}<\/pre>\n
            src\/enums\/greetings.ts<\/h3>\n
            \/**\r\n * A simple enum with various greetings\r\n *\/\r\nexport enum Greeting{\r\n    HELLO   = \"Hello\",\r\n    HOWDY   = \"Howdy\",\r\n    YO      = \"Yo\"\r\n}<\/pre>\n
            src\/utils\/helpers.ts<\/h3>\n
            \/**\r\n * A simple function that prints a message to the console.\r\n * @param msg - the string message to be printed\r\n *\/\r\nexport function broadcast(msg: string): void {\r\n    console.log(msg);\r\n}\r\n<\/pre>\n
            This code reflects three files, two subdirectories, and one for loop that prints out three greetings to the console. The use of the enum in the src\/enums\/greetings.ts file reflects something TypeScript provides that vanilla JavaScript does not. Note I have added string values to the enum values here to make iterating over the Greeting<\/code> enum easier.<\/p>\n
            Step 7: Compiling & Running<\/h2>\n
            Webstorm should automatically compile everything in the src<\/code> directory, including the directories and files in enums<\/code> and utils<\/code> into .js<\/code> versions in the dist<\/code> directory. If for some reason Webstorm has not done this, typing the npx tsc<\/code> command in the terminal will do the same. Below is the resulting project structure, including sub-directories and files, after compiling all the TypeScript files:<\/p>\n
            .\r\n\u2514\u2500\u2500 WebstormTypescript\/\r\n    \u251c\u2500\u2500 node_modules\r\n    \u251c\u2500\u2500 dist\/\r\n    \u2502   \u251c\u2500\u2500 enums\/\r\n    \u2502   \u2502   \u251c\u2500\u2500 greeting.js\r\n    \u2502   \u2502   \u2514\u2500\u2500 greeting.js.map\r\n    \u2502   \u251c\u2500\u2500 utils\/\r\n    \u2502   \u2502   \u251c\u2500\u2500 helpers.js\r\n    \u2502   \u2502   \u2514\u2500\u2500 helpers.js.map\r\n    \u2502   \u251c\u2500\u2500 index.js\r\n    \u2502   \u2514\u2500\u2500 index.js.map\r\n    \u251c\u2500\u2500 src\/\r\n    \u2502   \u251c\u2500\u2500 enums\/\r\n    \u2502   \u2502   \u2514\u2500\u2500 greeting.ts\r\n    \u2502   \u251c\u2500\u2500 utils\/\r\n    \u2502   \u2502   \u2514\u2500\u2500 helpers.ts\r\n    \u2502   \u2514\u2500\u2500 index.ts\r\n    \u251c\u2500\u2500 package.json\r\n    \u251c\u2500\u2500 package-lock.json\r\n    \u2514\u2500\u2500 tsconfig.json<\/pre>\n
            We can run the index.js<\/code> file directly via Webstorm by right-clicking within the file open in the editor and selecting run<\/em>. Alternatively, enter the command node dist\/index.js<\/code> in the Webstorm terminal. In either case, the following output should be visible in the WebStorm terminal:<\/p>\n
            hello, world!\r\nhowdy, world!\r\nyo, world!\r\n<\/pre>\n
            There we have it — TypeScript configured in Webstorm that still allows for the project to exist unbound to Webstorm. We can run this code effortlessly in a Node.js environment but still require some tweaking before it can be run in a browser — modern browsers don’t support the use of modules (at least not yet!).<\/p>\n
            The issue is because we are importing from multiple files (enums, utils, etc.) I’ve seen hacks, workarounds, and configurations ranging from clever to disgustingly complex hellbent on addressing this issue. The source of our woes is in the following two lines of code in our index.ts:<\/p>\n
            import {broadcast} from \".\/utils\/helpers\";\r\nimport {Greeting} from \".\/enums\/greetings\";<\/pre>\n
            If we’re using a single file, devoid of imports\/exports, this wouldn’t be an issue. However, the browser can’t handle the import\/export statements thus our code is currently confined to command-line execution via node.js. Rather than dredging through hacky approaches, we’ll address this simply via Webpack.<\/p>\n
            Step 8: Configure Webpack for Browser Support<\/h2>\n
            Webpack is a bundling tool<\/a> used (among other things) to combine a bunch of JavaScript and\/or TypeScript files into a single file. In this approach, we keep the flexibility of using multiple files without losing the ability to launch our application in a browser.\u00a0 To add Webpack support to our Typescript project we need only install two additional packages via npm:<\/p>\n
              \n
            1. webpack<\/strong> – The core functionality of webpack<\/li>\n
            2. ts-loader<\/strong> – Integration for bundling TypeScript files<\/li>\n<\/ol>\n
              Both of these can be installed with the following command:<\/p>\n
               npm install --save-dev webpack ts-loader<\/code><\/p>\n
              After the npm package manager installs these packages we need to tweak our package.json<\/code> file and add a new webpack.config.js<\/code> file — the file used to configure Webpack’s bundling options.<\/p>\n
              Step 8.a: Update package.json<\/h3>\n
              The package.json<\/code> file gets a new path for the \"main\"<\/code> entry and a new top-level scripts section with a build command targeting webpack. The updated file is as follows:<\/p>\n
              {\r\n  \"name\": \"typescript-ws-config\",\r\n  \"version\": \"1.0.0\",\r\n  \"description\": \"Just configuring typescript with Webstorm\",\r\n  \"main\": \"dist\/main.js\",\r\n  \"author\": \"Zack West <alphazwest@gmail.com>\",\r\n  \"license\": \"MIT\",\r\n  \"devDependencies\": {\r\n    \"ts-loader\": \"^9.3.0\",\r\n    \"ts-node\": \"^10.7.0\",\r\n    \"webpack\": \"^5.72.0\"\r\n  },\r\n  \"scripts\": {\r\n    \"build\": \"webpack\"\r\n  }\r\n}\r\n<\/pre>\n
              Note also the ts-loader and webpack dependencies that have been added. Optionally, the webpack-cli can be installed to issue build commands via the command line. Webstorm integrates well with webpack so we’re skipping over this one for now. The scripts.build = \"webpack\"<\/code> entry in this file is recognized by Webstorm and will help run webpack once it’s configured.<\/p>\n
              Step 8.b: Configure webpack.config.js<\/h3>\n
              The webpack.config.js file can get complex<\/a> because webpack can be used for a lot of things. Fortunately, our use-case is fairly simple so our configuration file will be as well. The essentials are as follows:<\/p>\n
                \n
              1. mode<\/strong> – tl;dr the format of the resulting output file. A value of production will produce a minified file that is not very pretty to look at. A value of ‘none’ is useful to show the basic formatting that happens.<\/li>\n
              2. entry<\/strong> – specifies the primary TypeScript file from which the resulting file will reference during bundling<\/li>\n
              3. output<\/strong> – specifies the target output file (bundled file) which in this case is main.js<\/code><\/li>\n
              4. resolve.extensions<\/strong> – tells webpack which order files should be used (read here<\/a>)<\/li>\n
              5. modules.rules<\/strong> – Tells webpack to integrate with ts-loader and to ignore the node_modules directory when searching for files to bundle.<\/li>\n<\/ol>\n
                These reflect a minimal webpack configuration file that should be enough to get our project running in the browser. The following is how this file looks in the proper json format:<\/p>\n
                const path = require('path');\r\n\r\nmodule.exports = {\r\n    mode: 'production',\r\n    entry: '.\/src\/index.ts',\r\n    output: {\r\n        path: path.resolve(__dirname, 'dist'),\r\n        filename: 'main.js'\r\n    },\r\n    resolve: {\r\n        extensions: ['.ts']\r\n    },\r\n    module: {\r\n        rules: [\r\n            {\r\n                use: 'ts-loader',\r\n                exclude: \/node_modules\/,\r\n            }\r\n        ]\r\n    }\r\n};<\/pre>\n
                Webpack is a powerful package that intelligently collects code imported throghout a project. Even with the minimal settings we have above, webpack will begin with our index.ts<\/code> file, construct a dependency graph (tree) and pull in only what is essential — read here for more on that<\/a>.<\/p>\n
                Step 8.c: Run Webpack via Webstorm<\/h3>\n
                \"typescript<\/a>
                Webstorm’s node integration makes running scripts easy by clicking little green start buttons.<\/figcaption><\/figure>\n
                Webstorm offers dynamic run options for many languages. When viewing the package.json file, there will be a tiny little green arrow representing a start button next to the \"build\": \"webpack\"<\/code> entry in the scripts section. Click this button and webpack will do its thing. Output similar to the following should appear in the run window of Webstorm:<\/p>\n
                \"typescript<\/a>
                Webpack’s bundler will output a series of metadata about the most recent build indicating any errors, the files produced, and the total time having been taken to run.<\/figcaption><\/figure>\n
                At this point, a new file named main.js<\/code> will appear in the dist<\/code> directory in our project. This file can be loaded safely in internet browsers and will get rid of the Uncaught ReferenceError: exports is not defined<\/code> message in the console view.<\/p>\n
                Github<\/h2>\n
                We’ve covered a lot of ground in this article for such a basic setup. I certainly felt frustrated when I first researched how to get a TypeScript project set up to run in a browser. If you’ve made it to this point in the article you are truly<\/em> determined and destined for great things. To save you having to read through it again, all the code covered here is kept on Github here<\/a> — use it freely<\/a>.<\/p>\n
                Note<\/strong>: With the addition of webpack-cli<\/code> this project can be compiled to JavaScript and bundled via the following commands:<\/p>\n
                npx tsc\r\nnpm run webpack<\/pre>\n
                Final Thoughts<\/h2>\n
                TypeScript brings a host of language constructs such as enums and static typing to JavaScript applications. It helps structure projects in a way that’s easier to scale, test, and maintain. Webstorm integrates with TypeScript natively but using a package manager like npm<\/code> and the ts-node<\/code> package can help ensure your project isn’t overly tethered.<\/p>\n
                In this article, we’ve seen the ease-of-use in which TypeScript can be set up, but also some obvious downfalls in the limitation of compiling imported code across multiple files in a way web browsers can handle. Fortunately, tools like webpack are available and can easily be configured to handle such cases. Check out the article Configuring TypeScript and Webpack for ThreeJS<\/em><\/a> to see how this approach can be used to accommodate popular JavaScript librarires.<\/p>\n","protected":false},"excerpt":{"rendered":"
                Typescript is a powerful language that provides javascript developers a means to add static typing, enums, interfaces, and other features of common software development languages like C# or Java. Webstorm is Jetbrains’ dedicated web-language IDE geared to specifically support languages like HTML, CSS, SASS\/SCSS, and Javascript. Webstorm offers native support for Typescript but a little […]<\/p>\n","protected":false},"author":2,"featured_media":2536,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[10],"tags":[615,616,617,614,618,613],"acf":[],"_links":{"self":[{"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/posts\/2530"}],"collection":[{"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/comments?post=2530"}],"version-history":[{"count":6,"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/posts\/2530\/revisions"}],"predecessor-version":[{"id":2733,"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/posts\/2530\/revisions\/2733"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/media\/2536"}],"wp:attachment":[{"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/media?parent=2530"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/categories?post=2530"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/tags?post=2530"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}