leo
commented
2 months ago After running bunchee with npx (Node.js) and then bunx --bun (Bun), I was able to confirm that this logic doesn't work in Bun, so it seems like we were running bunchee via Bun after all. Or, to be specific, Bun was automatically replacing the Node.js shebang with bun, which might've been a result of us using bun run --filter at the root.
Regardless, the summary is that bunchee doesn't seem to work on Bun. But the good news is that this logic seems to be the only thing that is not working in Bun — the rest is. Perhaps there's an equivalent that bunchee could use here that would work in both Node.js and Bun?
We just ran into the following error earlier, which was blocking our CI after having introduced
buncheeto a Bun monorepo:In this case,
buncheeannounces thattypescriptis not available, but the reality is that it's notrequirethat is throwing an error, but instead the fact thatm(presumably the current module) is not defined, which means that.requireis not even available and cannot be invoked.We temporarily fixed the problem by removing the module resolving logic entirely, which made it work:
As mentioned above, it's a Bun monorepo with several different workspaces, but
typescriptandtsconfig.jsonsit at the top, whilebuncheeis invoked withbunchee --tsconfig ../../tsconfig.jsonfrom a workspace.Perhaps it would make sense to switch over to an entirely different module resolving logic? Happy to give it a try and report back if it resolves our issue, so that you don't need to set up an entire reproduction Bun monorepo. Or perhaps you already have another idea for what the cause could be.
Like I said it is a Bun monorepo, but since
buncheehas a Node.js shebang in its binary entry point file, it should still be Node.js that is runningbunchee, unless I'm missing something.We're also not using
bun run --bunto overwrite the shebang.