How to share code between TypeScript projects?

Let's say I have two projects with following file structure

/my-projects/

  /project-a/
    lib.ts
    app.ts
    tsconfig.json

  /project-b/
    app.ts         // import '../project-a/lib.ts'
    tsconfig.json

I want to consume lib.ts located in project-a also from project-b. How to do that?

  • Release it as NPM module - absolutely don't want that, it's an overkill for such a simple use case. I just want to share one file between two projects.

  • Use import '../project-a/lib.ts' - doesn't work, TypeScript complains

'lib.ts' is not under 'rootDir'. 'rootDir' is expected to contain all source files.

  • Put tsconfig.json one level up so it would cover both project-a and project-b - can't do that, the TypeScript config is slightly different for those projects. Also it's not very convenient, don't want to do that.

Any other ways?


Since Typescript 3.0 this can be done with Project References.

Typescript docs: https://www.typescriptlang.org/docs/handbook/project-references.html

I believe you would have to move lib.ts into a small ts project called something like 'lib'

The lib project should have a tsconfig containing:

// lib/tsconfig.json
    {
          "compilerOptions": {
            /* Truncated compiler options to list only relevant options */
            "declaration": true, 
            "declarationMap": true,
            "rootDir": ".",   
            "composite": true,     
          },
          "references": []  // * Any project that is referenced must itself have a `references` array (which may be empty).
        }

Then in both project-a and project-b add the reference to this lib project into your tsconfig

// project-a/ts-config.json
// project-b/ts-config.json
{
        "compilerOptions": {
            "target": "es5", 
            "module": "es2015",
            "moduleResolution": "node"
            // ...
        },
        "references": [
            { 
                "path": "../lib",
                // add 'prepend' if you want to include the referenced project in your output file
                "prepend": true, 
            }
        ]
    }

In the lib project. Create a file index.ts which should export all your code you want to share with other projects.

// lib/index.ts    
export * from 'lib.ts';

Now, let's say lib/lib.ts looks like this:

// lib/lib.ts
export const log = (message: string) => console.log(message);

You can now import the log function from lib/lib.ts in both project-a and project-b

// project-a/app.ts 
// project-b/app.ts
import { log } from '../lib';
log("This is a message");

Before your intelissense will work, you now need to build both your project-a and project-b using:

tsc -b 

Which will first build your project references (lib in this case) and then build the current project (project-a or project-b).

The typescript compiler will not look at the actual typescript files from lib. Instead it will only use the typescript declaration files (*.d.ts) generated when building the lib project.

That's why your lib/tsconfig.json file must contain:

"declaration": true,

However, if you navigate to the definition of the log function in project-a/app.ts using F12 key in Visual Studio code, you'll be shown the correct typescript file. At least, if you have correctly setup your lib/tsconfig.json with:

"declarationMap": true,

I've create a small github repo demonstrating this example of project references with typescript:

https://github.com/thdk/TS3-projects-references-example


This can be achieved with use of 'paths' property of 'CompilerOptions' in tsconfig.json

{
  "compilerOptions": {
    "paths": {
      "@otherProject/*": [
        "../otherProject/src/*"
      ]
    }
  },
}

Below is a screenshot of folder structure.

enter image description here

Below is content of tsconfig.json which references other ts-project

{
  "compilerOptions": {
    "baseUrl": "./",
    "outDir": "./tsc-out",
    "sourceMap": false,
    "declaration": false,
    "moduleResolution": "node",
    "module": "es6",
    "target": "es5",
    "typeRoots": [
      "node_modules/@types"
    ],
    "lib": [
      "es2017",
      "dom"
    ],
    "paths": {
      "@src/*": [ "src/*" ],
      "@qc/*": [
        "../Pti.Web/ClientApp/src/app/*"
      ]
    }
  },
  "exclude": [
    "node_modules",
    "dist",
    "tsc-out"
  ]
}

Below is import statement to reference exports from other project.

import { IntegrationMessageState } from '@qc/shared/states/integration-message.state';

I think that @qqilihq is on the right track with their response - Although there are the noted potential problems with manually maintaining the contents of a node_modules directory.

I've had some luck managing this by using lerna (although there are a number of other similar tools out there, for example yarn workspaces seem to be somewhat similar, although I've not used them myself).

I'll just say upfront that this might be a little heavyweight for what you're talking about, but it does give your project a lot of flexibility to grow in the future.

With this pattern, your code would end up looking something like:

/my-projects/
    /common-code/
        lib.ts
        tsconfig.json
        package.json
    /project-a/
        app.ts (Can import common-code)
        tsconfig.json
        package.json (with a dependency on common-code)
    /project-b/
        app.ts (Can import common-code)
        tsconfig.json
        package.json (with a dependency on common-code)

The general theory here is that the tool creates symlinks between your internal libraries and the node_modules directories of their dependant packages.

The main pitfalls I've encountered doing this are

  • common-code has to have both a main and types property set in its package.json file
  • common-code has to be compiled before any of its dependencies can rely on it
  • common-code has to have declaration set to true in its tsconfig.json

My general experience with this has been pretty positive, as once you've got the basic idea understood, there's very little 'magic' in it, its simply a set of standard node packages that happen to share a directory.


It seems we've got a few options here:

(1) Put both projects in a mono repo and use answer given by @ThdK using TS project references

NOT GOOD if you don't want a mono repo

(2) Use Lerna - see answer by @metric_caution

NOT GOOD if you can't be bothered to learn Lerna / don't want to publish your shared files to npm

(3) Create a shared npm package

NOT GOOD if you don't want to publish your shared files to npm

(4) Put shared folders in a "shared" directory in project A and write a script to copy files in the shared folder from project A to project B's shared folder that is executed on a git push OR a script to sync the two folders.

Here the script can be executed manually when copying / syncing is required. The copying / syncing could also be done prior to a git push using husky and the shared files added to git automatically in the script.

Since I don't want a mono repo and I can't be bothered to publish an npm package for such a pathetic purpose I'm gonna go with option 4 myself.