Perhaps there is a different approach that has not crossed my mind.
I have spent some time exploring various methods like js/ts with npm link, git submodules, tsconfig paths, symlink, npm/pnpm/yarn workspace, npm pack & npm link, package.json exports, package.json commonjs/module, and nx(nrwl)/lerna. Each method comes with its drawbacks, and it seems there are no straightforward standards to follow.
Issue:
As a developer,
I want to write code and reuse it.
I want to initiate a new project and utilize only the necessary code.
I have existing code that needs to be shared across multiple projects while allowing for updates.
I am seeking clear instructions on how to achieve this.
My IDE of choice is JetBrains IntelliJ IDEA.
I aim to avoid complicating the codebase with package management, configurations, commands, or other techniques that hinder development speed and create unnecessary steps.
A monorepo is not feasible due to the large number of projects, and the IDE's performance suffers when handling tasks like searching and replacing within a monorepo setup.
The structure of the code is as follows:
/unit_domain_project_1
. .git
. package.json
. /src
. . /units # library
. . . /meter.ts # module
. . . /meter.test.ts # unit testing
. . /nodejs
. . . # Node.js code in TypeScript not compilable in browser
. . /browser
. . . # Browser code in TypeScript not compilable in Node.js
/furniture_project_2
. .git
. package.json
. /src
. . table.ts # here I aim to reuse only 'units'
/building_project_3 # additional nesting example
. /src
. . house.ts # here I aim to reuse 'table' along with 'units/meter'
Solution:
The most effective solution I have discovered is using symlink such as
ln -s $ABSOLUTE_PATH_TO_PROJECT_1/unitsQuery:
How can I effectively reuse the 'units' code?
(Kindly provide step-by-step guidance.)
Drawbacks of Existing Approaches: (The following approaches present interrelated issues)
git submodules- Demands manualgit pull/pushin each project.symlink- Necessitates shell scripting like
when working with Docker.copy ./linked_code_source ./linked_codetsconfig paths- Lacks support for relative paths beyond the parent(base), leading to IDE dependency resolution issues.package.json exports: {'*./'}- Leads to complexity withpackage.json commonjs/module; TypeScript must be transpiled into module JavaScript, causing challenges with dependencies and path resolution, requiring significant effort to make it function correctly.npm link- Does not integrate well with Docker, necessitating additional shell scripting.npm/pnpm/yarn workspace- Relies heavily on specific versions of npm/node, either creating symlinks or copying files without updating them, mandating post-install scripting and package rebuilds.npm pack & npm link- Requires an update script to manage changes.nx(nrwl)/lerna- Emphasizes adherence to their folder structure and build commands, thereby mandating code segmentation into libraries, along with configuration setups andpackage.jsons, introducing unnecessary complexities.