In Typescript 3.0 and above, utilizing Project References allows for seamless organization of code.

If you need to move lib.ts into a new project named 'lib', follow these steps:

// lib/tsconfig.json
{
      "compilerOptions": {
        /* Important compiler options */
        "declaration": true, 
        "declarationMap": true,
        "rootDir": ".",   
        "composite": true,     
      },
      "references": []  
    }

Include the reference to the lib project in both project-a and project-b tsconfigs:

// project-a/ts-config.json
// project-b/ts-config.json
{
    "compilerOptions": {
        "target": "es5", 
        "module": "es2015",
        "moduleResolution": "node"
        // ...
    },
    "references": [
        { 
            "path": "../lib",
            "prepend": true, 
        }
    ]
}

Create an index.ts file in the lib project exporting all shared code:

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

For example, assume lib/lib.ts contains:

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

Now, import the log function from lib/lib.ts in project-a and project-b:

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

To enable intelissense, build both projects using:

tsc -b 

The typescript compiler relies on declaration files (*.d.ts) generated during building rather than the actual typescript files from lib.

Ensure your lib/tsconfig.json file has:

"declaration": true,

If configured correctly, F12 navigation to the log function in project-a/app.ts should display the correct typescript file.

A sample github repo showcasing project references with typescript can be found here:

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

To utilize the 'paths' property of 'CompilerOptions' in tsconfig.json, you can achieve the desired outcome.

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

Displayed below is a snapshot of the directory structure.

https://i.sstatic.net/JG19V.png

Here is the content of tsconfig.json that makes reference to another TypeScript 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 an example import statement used to access exports from another project.

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

I believe @qqilihq is heading in the right direction with their insights - Despite the potential challenges associated with manually curating the contents of a node_modules directory.

In my own experience, I have found success in utilizing lerna for this purpose (although there are various other tools available, such as yarn workspaces which offer similar functionalities, though I haven't personally experimented with them).

I must mention that this approach may seem a bit complex for your current requirements, but it does provide your project with ample flexibility for future growth.

Following this methodology, your code structure might resemble:

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

The underlying concept here involves creating symbolic links between your internal libraries and the node_modules directories within their dependent packages.

Some key challenges I've faced while implementing this include

• common-code requiring both 'main' and 'types' properties to be set in its `package.json` file
• common-code needing to be compiled before any dependencies can utilize it
• common-code necessitating 'declaration' to be set true in its `tsconfig.json` file

Overall, my overall experience with this method has been quite favorable; once you grasp the core concepts, it becomes more about following standard practices rather than relying on 'magic', essentially making it a collection of conventional node packages sharing a directory.

As the sole developer working on two projects that share a common code folder, I have implemented a two-way real-time syncing solution to keep the shared code in sync between the two projects.

Project A
 - shared/ -> 2-way sync with Project B
 - abc/

Project B
 - shared/ -> 2-way sync with Project A
 - xyz/

This setup was quick to implement and offers several benefits:

• No need for configuring and managing mono-repos or multiple tsconfig files
• No build step required to get the latest code, updates are instant
• Works seamlessly with cloud build tools as the shared code is within the repository instead of being symlinked
• Easier debugging locally since all files are within the project structure
• Ability to implement checks on the shared folder using commit hooks/husky to ensure code quality

If collaborating with other team members in the future, I can recommend using this sync tool as part of the project setup.

Symlinking dependencies can often simplify things, and occasionally it's worth symlinking tsconfig.json too.

While not a one-size-fits-all solution, this approach can be effective in many scenarios, particularly when paired with tools like bun or deno.

Here's an alternative method you might find interesting - consider utilizing a git submodule in your project. Check out this resource for more information on how to use Git submodules.