bun and monorepos

[andeeplus]

Hi,

thanks a lot for your effort and the hard work you've put into this project. The new registry is really exciting, though I've hit a snag with package publishing that I hope you can help with.

While experimenting with bun, I've encountered some limitations, especially around dependency resolution in monorepos.
I've read and re-read the docs but maybe those topics are not yet covered in full, or maybe I overlooked it.

For now, my main concern are outlined below:

• path aliasing not working correctly

I didn't find any prohibition to use path aliasing, but maybe it's underlying in the docs in a not explicit way.
I'm allowed to use it? I've noticed that they are not resolved properly, and they are basically transformed in relative path, i.e. '@/global/app-logger'; > './@/global/app-logger';
Should I allowImportingTsExtensions and preferably just use relative paths with extensions to fix the issue?

• Sloppy import

I've seen that the published package of hono has a key that is not defined in the schema https://jsr.io/schema/config-file.v1.json named unstable where sloppy import, isn't enough to have a package json?

https://jsr.io/docs/publishing-packages#relative-imports

• package json modified on publish
• bin field is being stripped from package.json upon publication

When publishing packages to the jsr package registry, it appears that the package.json is being modified, and several fields are being stripped out, including the crucial bin field. This behavior affects the usability of packages intended to provide command-line tools or executables. I couldn't find any information about this behavior in jsr docs, am I doing something wrong?

• ts to js
  When the package is loaded in bun runtime the reference is via the npm layer and I've seen that most of the code is converted to js, but not all of it. Is this because the file that are not converted have not being exported? Can you confirm?

• dependency resolution
  In order to have the package published I did some tricks adding peerDependencies as devDependencies too because it was the only way the publishing could go through. Really I was playing a bit with it but I couldn't find a proper meaning to it except some internal jsr logic I'm ignoring due the fact I'm not really into deno, maybe reading some Deno docs can help me?

I was trying to publish a wide set of packages I was playing with in the past months. Maybe having a look into the repo can help you understand better the issues I've encounterd. Looks like a pretty extended playground to investigate possible issues or misconfiguration.

https://jsr.io/@ecopages / https://github.com/ecopages/ecopages

When i started to write this issue it was mainly related with the absence of the bin file in the node modules but while I was writing I started to dive into the node modules packages and I've noticed other stuff so I started writing in waterfall mode.

Please let me know if you'd prefer for me to split this into multiple tickets, shift our conversation to the discussion panel, or if you consider this issue comprehensive enough to proceed as is.

thanks a lot

[andeeplus]

For the record, here's what I've managed to do so far:

• I've enabled allowImportingTsExtensions and tidied up the imports across all packages.
• I attempted to utilize the imports in jsr.json, but unfortunately, it didn't work out. I tried importing with both npm:@jsr/scope__package and jsr:@scope/package.
• I also tried adding the individual packages as direct dependencies, but that didn't work either. It ended up replacing all the library imports with an npm: prefix, which incorrectly pointed to the jsr scope.

I believe the most progress I've made so far involves the following approach:

package.json
"dependencies": { "@ecopages/postcss-processor": "workspace:*" }

jsr.json
"imports": { "@ecopages/postcss-processor": "jsr:@ecopages/postcss-processor@0.1.7", }

It seems like I previously encountered an issue that might have been related to using the latest tag. I later realized that this was the tag not an accepted in jsr specifiers. Following that, I ran into another challenge:

error: Could not find a matching package for 'npm:postcss@^8.4.32' in a package.json file. You must specify this as a package.json dependency when the node_modules folder is not managed by Deno.

I'm finding this quite challenging to navigate. I'm confident there's a solution out there, or perhaps my specific use case isn't fully supported yet?

If anyone could offer some guidance or point me in the right direction, I'd greatly appreciate it.

Possible related ticket:
#448
#526

[andeeplus]

A small advance in there, using specific version fix the issue with the matching package, but now I've got a new error:
@ecopages/bun-postcss-loader release:jsr: Failed to publish @ecopages/bun-postcss-loader at 0.1.7: failed to build module graph: Module not found "file:///src/@ecopages/postcss-processor".

Looks that now most of my issues can be considered solved, except the bin one and this one but for this we already have #448

I'll open a new issue for the bin issue.