This describes the entire compile process in-depth, focusing on how the compiling script works, and why was the script written like that

This is sub-layout for documentation pages

Top

Typescript compiler allows path referencing. In code, there can be token, which is later defined in tsconfig.json file.

The main point is to get rid of relative paths referencing, such as:

    import {HashSet} from '../../../../../../../containers/data/HashSet.ts';

     export class A
     {
        constructor()
        {
        }
     }
    

This can be solved using tokens, as follows:

file.ts example:

    import {HashSet} from '@HashSet';

     export class A
     {
        constructor()
        {
        }
     }
    

HashSet.ts example:

     export class HashSet
     {
        constructor()
        {
          //TODO
        }
     }
    

tsconfig.json example:

      {
        "compilerOptions": {
          "module": "commonjs",
          "target": "es5",
          "noImplicitAny": false,
          "sourceMap": false,
          "outDir": "build/src",
          "baseUrl": ".",
          "paths": {
            "@HashSet": ["./app/model/other/containers/hashSet/HashSet"]
          }
        },
        "exclude": [
          "app/view/**",
          "src/node_modules",
          "build"
        ]
      }
    

1.1 The problem

Upon compilation, the file.ts will become file.js which will contain valid javascript.
During compilation, the Typescript uses the tokens and path substitution to know what file in required, and where it is.
However, in final .js file, The path is not substituted.

The final .js file can look something like this:

      var HashSet_1 = require('@HashSet');

      //here is javascript ugly code
    

The problem is, that '@HashSet' is not a file, nor path and it does NOT exist.
Therefore, the final javascript fill not work.

1.2 Solution

The idea is to use bash script to traverse every .js file after typescript compilation, and using the tsconfig.json file, where all tokens are defined, substitute such a token in every .js file to correcponding path. Unfortunatelly, the path must be relative, therefore it is precomputed by the replacing script.

The code on client side is compiled to one .js file (bundle.js)
The code, however, can not contain 'import'.
The dependency is solved adding following line:

      ///<reference path="./gameLobby/GameLobby.ts" >

      //some other typescript code...
      

That makes sure that the .ts file is compiled and put above the final javascript code, so that the final class can be used.

When, however, using export keyword:

      export class
    

it does NOT exist on client side, and can NOT be used, because importing / exporting keywords are compiled to require keyword.
Require keyword does not exist in client-side javascript.
To solve this issue, compiling script takes all .ts files, that are marked as shared, and removes the export keyword from them.
Then, client code is compiled, and after that, the substitution process is reverted.
Therefore, do NOT compile client and server at same time, as server compile may fail, because in one particular moment the file will not contain 'export' keyword.

Sometimes is needed to share javascript / typescript code between client and server to avoid writing duplicite code.
In order to do this, some ugly code substitution automation must be done, however, the written bash script that does it is reliable, as long as user works with it how he should.

The compilation process for shared source code (for both server and client) is as follows:

• compileClient.sh bash script is called
• for all *.ts files in shared directory, do:
• comment out all lines that are like import {.*} from '@.*';
• comment out all export keywords in class / enum definitions
• let typescript compile the client side from all needed source files
• for all *.ts files in shared directory, do:
• reverse the changes done above