All solutions have one problem: you must use relative imports

[Danielku15]

I stumbled over this RFC researching solutions for the problem described in this repo: how to best use source-sharing within a mono repo to avoid a build step for cross references.

While most solutions sound promising there is a key problem to all of them: You must use relative path or imports for all imports within a package. If you use absolute paths or package specific ts-paths things fall apart.

Here a simplified example of what I mean:

packages
    lib1 
        src
            fun2.ts 
                // 1. import {fun1} from '@src/shared'; 
                // 2. import {fun1} from 'src/shared';
                // 3. import {fun1} from './shared';

            fun1.ts
                // 1. import { shared } from '@src/shared'
                // 2. import { shared } from 'src/shared'
                // 3. import { shared } from './shared'
            shared.ts
    lib2
        src
            file1.ts
                // import {fun2} from '@brand/lib1/fun2';

Depending on what paths you use for imports, the imports will fail at some point:

• 1/1, 1/2, 1/3: import of '@brand/lib1/fun2' already fails because @src/ points to the lib2 sources
• 2/1, 2/2, 2/3: import of '@brand/lib1/fun2' already fails because src/ points to the lib2 sources
• 3/1: import of '@brand/lib1/fun2' works, but import of '@src/shared' fails because @src/ points to the lib2 sources.
• 3/2: import of '@brand/lib1/fun2' works, but import of 'src/shared' fails because src/ points to the lib2 sources.
• 3/3 import of '@brand/lib1/fun2' works and import of './shared'

I didn't test this through but I also expect things get tricky regarding automatic imports by the IDE.

I guess you either need to ensure relative paths or you use the full @brand/package syntax across the whole codebase.

Happy to hear any inputs how this challenge can be solved.

[kalvenschraut]

solution is to use subpath imports then the alias should all resolve with respect to the cloest package.json and this should just be native node behavior. No need for tsconfig/vite aliases then unless an edge case is hit where the resolve doesnt support them. Which those cases are being fixed as they are reported.

I think the 2nd option laid out in the README is the best option and the only downside being extensionless imports being more of a pain, while I am big fan of forcing them. Most editors have auto import and can be configured to add them so I have had very little problems with that direction. Rarely a concern for my team and how I have things setup. Going try out that setup soon and try make it work in the codebases I manage. I could see the non standard export being a pain I suppose so wouldnt hate 4/5 solutions either