It seems there may be some confusion in your question, but I believe you are interested in a feature similar to pnpm workspaces: . It's unclear how this concept would interact with different package managers.

You can find an example I've created here: https://github.com/quentinkrammer/mono.

To see it in action, navigate to mono/app1 and run pnpm install, followed by pnpm dev.

This image provides a visual representation of the process: https://i.sstatic.net/HPC6V.png

In this setup, the App2 workspace is linked to the node_modules folder of App1. Any changes made in App2 will immediately reflect in App1. This mechanism applies to type checking and Hot Module Replacement (HMR) as well.

I hope this explanation proves useful to you.

To begin, navigate to the main directory of your monorepo and run npm init -y to generate a package.json file. Next, install TypeScript and ts-node as development dependencies with the command

npm install --save-dev typescript ts-node

. After that, create a tsconfig.json file in the root directory with the following configuration:

{
   "compilerOptions": {
     "module": "es2020",
     "resolveJsonModule": true,
     "esModuleInterop": true,
     "rootDir": ".",
     "outDir": "./dist"
   },
   "include": [
     "apps/*/src",
     "common/*/src"
   ]
}

Now, within each app's folder (/apps/app1 and /apps/app2), update the tsconfig.json as follows:

{
   "extends": "../../tsconfig.json",
   "compilerOptions": {
     "outDir": "./dist",
     "rootDir": "./src",
     "jsx": "react-jsx"
   },
   "include": [
     "src"
   ]
}

Additionally, make changes to the package.json file in each app's folder (/apps/app1 and /apps/app2) and then execute npm start to launch the app in watch mode:

{
   "scripts": {
     "start": "ts-node src/index.ts"
   }
}

Finally, any modifications made to files within the /common directory will be immediately reflected when running the apps!

Regrettably, Windows does not provide straightforward support for folder links, requiring manual command input.

In contrast, Linux allows me to effortlessly incorporate an entire folder from another repository into the current one without rebuilding everything. This method is more reliable than various path mapping and aliases, which often result in issues either with web functionality or unit testing. Furthermore, incorrect path mappings can disrupt source maps, creating debugging challenges.

Nevertheless, this approach is not recommended for large packages.

An issue arises with import path mapping; all paths are made relative, making relocation problematic.

It is advisable to create a separate package if the code is intended to be shared among multiple applications. Doing so allows for easier management of changes and unit tests while focusing on component development.

A separate package will always use fully qualified module paths rather than relative paths, simplifying the process of copying and handling multiple packages.

While a monorepo may streamline deployment processes by reducing dependencies, it is not a universal solution. The primary purpose of a monorepo is to have a unified build and deploy script, enabling integration of dependent npm packages within a single script.

As the codebase grows, components should exist outside of the monorepo to facilitate their reuse across different projects. For instance, if developing accounting software for one client and a social network for another, both projects could share reusable components sourced from a central registry.

Creating a single monorepo for all clients and projects may not be the most effective solution in the long run.

For apps to recognize common/package1 as a package and import it from a Javascript module instead of raw Typescript files, the package must be built in some way - there's no avoiding it. This approach simplifies consumption for the apps since they don't need to worry about the dependencies or build specifics of the package.

Utilizing workspaces streamlines the process. Simply list the apps and common package in the main package.json like so:

{
  "workspaces": [
    "common/package1",
    "apps/app1",
    "apps/app2"
  ],
  ...
}

This will compile the projects into the top-level node_modules directory for mutual access.

The common/package1 needs to be configured as a package and a watcher should continue building it upon updates:

{
  "name": "common/package1",
  "version": "1.0.1",
  "scripts": {
    "watch": "tsc --watch"
  },
  "module": "dist/index.mjs",
  "types": "dist/index.d.ts",
  ...
}

(This example assumes the use of plain tsc with a setup for building a single file module - feel free to request an illustration of tsconfig or Rollup setup)

The benefit is that you can now treat it as a regular dependency in the apps:

{
  "name": "apps/app1",
  "dependencies": {
    "common/package1": "^1"
  },
  ...
}

If the app's build tool is able to detect changes, it will automatically rebuild when common/package1 is updated (i.e. its watcher runs). It should function smoothly. Keep me posted on your progress.

What you're mentioning is referred to as the concept of going buildless.

While there are numerous articles discussing this topic, I'd like to highlight the modern-web getting started article. Our team is currently exploring the use of web components and adopting a buildless approach within a mono repo structure.

As an illustration:

Shown below is our configuration snippet for setting up storybook using @rollup in the main.js file.

module.exports = {
  stories: ['../packages/*/stories/*.stories.ts'],
  rollupConfig(config) {
    config.plugins.unshift(
      typescript(),
      nodeResolve(),
      commonjs({
        include: /node_modules/,
      }),
    );

    return config;
  },
};

Additionally, here's our npm script for running storybook through the web development server, where we utilize tsc for compilation checking and linting.

"storybook": "tsc --noEmit && concurrently -k -r \"tsc --noEmit --watch --preserveWatchOutput\" \"wds -c .storybook/server.mjs\"",

We only compile to dist when publishing our npm packages. All changes at the .ts level are compiled on-the-fly and reflected immediately in storybook. This applies to internal package dependencies as well.