Workspace inter-dependencies not found during build

[silverbucket]

What version of Bun is running?

1.2.2+c1708ea6a

What platform is your computer?

Darwin 23.6.0 arm64 arm

What steps can reproduce the bug?

Using workspaces:

    "workspaces": [
        "packages/*"
    ]

I have a package which depends on another package:

• @sockethub/client depends on @sockethub/activity-streams
  In the package/sockethub-client/package.json:

"devDependencies": {
        "@sockethub/activity-streams": "workspace:*",
        ...
}

However, when trying to build, the dependency is not found.

bun build ./src/sockethub-client.ts --outdir=dist/ --target=browser --sourcemaps
7 | import { ASFactory, type ASManager } from "@sockethub/activity-streams";
                                              ^
error: Could not resolve: "@sockethub/activity-streams". Maybe you need to "bun install"?
    at /Users/njenning/code/projects/sockethub/packages/client/src/sockethub-client.ts:7:43

Running bun install does not fix the issue.

What is the expected behavior?

The package dependency should be found in the workspace.

What do you see instead?

bun build ./src/sockethub-client.ts --outdir=dist/ --target=browser --sourcemaps
7 | import { ASFactory, type ASManager } from "@sockethub/activity-streams";
                                              ^
error: Could not resolve: "@sockethub/activity-streams". Maybe you need to "bun install"?
    at /Users/njenning/code/projects/sockethub/packages/client/src/sockethub-client.ts:7:43

Additional information

The repo can be accessed here (switch-to-bun branch):
https://github.com/sockethub/sockethub/tree/switch-to-bun

[RiskyMH]

I can confirm this. It is very weird as can resolve in ./packages but not in ./packages/client (even with its node_modules deleted).

A simple command I used:

bun --print "require.resolve('@sockethub/activity-streams')"

[RiskyMH]

Update, removing tsconfig.json makes it work again.

My theory is that it is being relative to where the cwd/main tsconfig.json is and not relative to the extended one in root.
https://github.com/sockethub/sockethub/blob/switch-to-bun/tsconfig.base.json#L23-L25

(I don't think you need the tsconfig to map your imports anyway as TS should be smart enough to read it from node_modules - at least if you add types field with the path passed to it)

[dylan-conway]

Is it possible just the import needs to be changed to reflect exports from ./packages/activity-streams/package.json?

- import { ASFactory, type ASManager } from "@sockethub/activity-streams";
+ import { ASFactory, type ASManager } from "@sockethub/activity-streams/dist/activity-streams.js";

Or update exports in activity-streams/package.json:

"exports": {
-     "./dist/activity-streams.js": "./dist/activity-streams.js"
+     ".": "./dist/activity-streams.js"
}

[RiskyMH]

Another update, it appears removing exports in activity-streams package also fixes this. (along side deleting tsconfig.json in client package

My new theory is if there is exports, then it doesn't check main anymore and as no conditions Bun respects, it just fails: https://bun.sh/docs/runtime/modules#importing-packages

[silverbucket]

Is it possible just the import needs to be changed to reflect exports from ./packages/activity-streams/package.json?

• import { ASFactory, type ASManager } from "@sockethub/activity-streams";

• import { ASFactory, type ASManager } from "@sockethub/activity-streams/dist/activity-streams.js";
  Or update exports in activity-streams/package.json:

"exports": {

• "./dist/activity-streams.js": "./dist/activity-streams.js"
  

• ".": "./dist/activity-streams.js"
  

}

By default, the import should use the typescript file, and only if you explicitly need the JS version you can include it. That's what I was going for with that exports definition. I've removed it for now, will revisit that once I get bun working in this branch.

[silverbucket]

Just to confirm, removing the tsconfig.json resolved the issue. I had planned to remove as much of the tsconfig I have littered around the repo as possible, so this is a fine work-around for now. I've also removed the exports directive from the package.json for now.