path-mapping will import module twice when use tsc

[ohroy]

What version of Bun is running?

1.1.43

What platform is your computer?

No response

What steps can reproduce the bug?

tsconfig

{
//omit
    "paths": {
      "@/*": ["./src/*"]
    }
}

then, if you use tsc build to dist, the tsc NOT deal anything about paths, so if other package import this package, what will happen ?

it will import the the same module 2 times,

1 times for ts, and other for dist/js

What is the expected behavior?

No response

What do you see instead?

No response

Additional information

No response

[ohroy]

This can be temporarily solved by tsc-alias, but this bug is very hidden and many people may encounter it but not pay attention to it.

Perhaps we can update the documentation to explain this unexpected behavior?

[RiskyMH]

@ohroy is this when using bun runtime with tsc (ie bunx --bun tsc)? I'm having a hard time understanding the root issue here or how to repoduce.

[ohroy]

@RiskyMH Thanks for quick response
Now let me explain in detail
When tsc compiles ts to js, ​​it does not process the paths alias in tsconfig

    "paths": {
      "@/*": ["./src/*"]
    }

source.ts

import xx from '@/xx'

after tsc build

dist.js

import xx from '@/xx'

tsc not care about alias, but bun care it!

SO, when dist and src and alias both exist, what file will bun resolve ?

The answer is BOTH

Bun will import xx.ts when exec dist.js (by parse alias to @/src, there are ts files), and bun will also import xx.js when some file not import by alias.

dist2.js

import xx from './xx'

Then, same xx, but different path, the same logic will be exec 2 times.

[ohroy]

This may be a marginal case, but it happens in a subtle and coincidental way that is not easily noticed.

If anyone encounters the same strange problem, please use tsc-alias after tsc build to replace alias with a certain path to avoid bun's error return to ts

[RiskyMH]

Oh I see the problem now thanks! What solution would you like Bun to do though?

As node (not reading tsconfig.json) would just error out completely, and as Bun has no way of knowing that you didn't want path specified in tsconfig its a little hard.

Edit: also good thing in Bun we don't need tsc and can instead just run source files to simplify everything :)

Overall, I think your tsc-alias is a good solution.

[ohroy]

Thanks！

Maybe this is not a bug, but overall it may lead to undefined results, which I think is worth optimizing.

In monorepo, compiling the library into js and publishing it to npm is a common scenario.
Now, in order to publish the package, I have to set the exports field to dist/.js.
But if the exports field in package.json can be specifically specified for bun as src/.ts, while not affecting other users' normal use of dist/*.js when the package is published. That would be perfect.

I thought of 3 solutions，

1. Extend nodejs's conditional exports, add bun type, bun will give priority to it when parsing packages, so that users can specify it as a ts file. https://nodejs.org/api/packages.html#conditional-exports, I think this is the perfect solution, but it may require some extra work
2. Respect node.js,if only package A, do not need to change anything. But if A ref B, then not care B package's tsconfig, just thown error like nodejs
3. Do not change anything but update doc to warning

This is just a starting point, maybe someone else has a better idea.

[RiskyMH]

Extend nodejs's conditional exports,

guess what, you can use "bun" export condition already :)

[ohroy]

💯 amazing!!! great bun!!!

I just tested, It solves the problem perfectly !!!

Thanks! : )