In my monorepo project, I utilize yarn workspaces and lerna, with all components written in TypeScript. Each module is housed in subfolders like packages/module-n, and every module contains its own package.json file with the following entries:
"main": "dist/index.js",
"types": "dist/index.ts",
The source code for each package resides in packages/module-n/src/index.ts, which is standard practice.
While building from the command line or publishing works seamlessly thanks to tsconfig.json and a build script in every package folder, everyday code editing in VSCode presents challenges, even with tsc --watch running across all packages to maintain linked dependencies.
When attempting to navigate to a definition referencing a peer package by command-clicking, VSCode directs me to
packages/package-n/dist/index.d.tspackages/package-n/src/index.ts, causing inconvenience. Moreover, during refactoring with F2, occasional modifications to dist/index.d.ts files require restarting build:watch due to errors arising from TypeScript detecting manual changes in **/dist/index.d.ts.
To address this issue, I've implemented two scripts in the root package.json. Though functional, I'm not entirely satisfied with my solution:
"use-dev-typings": "lerna exec \"replace --quiet dist\\/index\\.d\\.ts src/index.ts package.json\"",
"use-prod-typings": "lerna exec \"replace --quiet src\\/index\\.ts dist/index.d.ts package.json\""
Both scripts are utilized in the same root package.json as shown below:
"build": "yarn use-prod-typings && lerna run build",
"build:watch": "lerna run build; yarn use-dev-typings && lerna run --parallel build:watch",
The objective is to patch all packages/package-n/package.json files before initiating edits in VSCode by using
yarn build:watch</code. This process involves replacing <code>"types": "dist/index.d.ts""types": "src/index.ts", resolving issues related to command+clicking and refactoring. For one-off builds (e.g., prior to publishing), "types" revert back to "dist/index.d.ts".
I am open to suggestions on alternative approaches to achieve the desired outcome. There is concern about accidentally committing "src/index.ts" or releasing a version with this value included. To avoid bloating my packages, the contents of src/*.ts are excluded from npm releases.