Lets say there is a monorepo with package A and B.
Package A is dependent on B. Package B is also published in npm registry. So when installing dependencies it does not install the package B from npm registry instead it symlinks to the local package B as intended.
But is there any way to avoid this behvaiour and always resolve package from npm registry?
Currently, it seems it's not possible out-of-the-box. For example, nohoist option in yarn is for packages-dependencies which don't exist in the monorepo. For example, react-native and so on. For same-monorepo packages being consumed by their sibling packages, nohoist does not work, I tried setting it on root package.json and also on the package. It does not work.
Notice I said "out-of-the-box".
I came here looking for a solution because I want to migrate my custom ESLint plugins to my npm package monorepo which happens to consume them.
The challenge is, ESLint plugins are not ESM, they are CJS, and in TS/pure ESM monorepo, ESM and CJS don't play well together.
My CJS ESLint plugins would get hoisted and ESLint plugin would refuse to load them, completely breaking my VSCode linting.
I came up with an idea to avoid this hosting by keeping npm packages which should not be hosted with a different name, for example, B-temp, and then, on CI, during publishing, rename them last second before publishing to npm to B.
This way, during local yarn/npm i call, local monorepo package B-temp would not get recognised and therefore, not hoisted. The yarn would fetch B from the internet. I could keep b-temp in ESM (set "type": "module" in package.json) then use esbuild to transpile to esnext-spec CJS (no transpiling to ES5 etc), then publish those dist/*.cjs.js builds to npm — except before publishing, edit the package.json, remove the "ESM-ness" — "type": "module" and exports.
© 2022 - 2024 — McMap. All rights reserved.
