error: Uncaught (in promise) Error: Unable to output during bundling. about deno_emit

[gm112]

This is frustrating because deno bundle is being deprecated, and this is the replacement. Definitely considering switching from Deno because of the developers negligence to giving users a proper solution forward when deprecating features...

EDIT:

I would highly suggest using a different package all together. None of my Deno projects work with deno_emit, even the most barebones example. Its honestly frustrating.

See https://esbuild.github.io/getting-started/#deno

[yacinehmito]

This is frustrating because deno bundle is being deprecated, and this is the replacement. Definitely considering switching from Deno because of the developers negligence to giving users a proper solution forward when deprecating features...

deno bundle is deprecated, not defunkt. It is still available and you are free to use it. deno_emit is the intended replacement. The feedback is crucial to make sure that deno_emit eventually works just as well as deno bundle. There is no negligence here, as deno_emit keeps receiving updates.

[gm112]

This is frustrating because deno bundle is being deprecated, and this is the replacement. Definitely considering switching from Deno because of the developers negligence to giving users a proper solution forward when deprecating features...

deno bundle is deprecated, not defunkt. It is still available and you are free to use it. deno_emit is the intended replacement. The feedback is crucial to make sure that deno_emit eventually works just as well as deno bundle. There is no negligence here, as deno_emit keeps receiving updates.

My point is that an important feature is being deprecated without a fully suitable replacement. Deno 2.0 is on the horizon, so I don't really agree with your stance. To my understanding, the bundle command is on its way out officially with 2.0. If Deno is to be taken seriously by developers, shouldn't there be more care put towards the developer experience on these sort of things?

I highly promoted Deno at my workplace and made use of it, and now am having second thoughts on using it. One good thing that Deno at least does well is that, its not too difficult to select a specific version of Deno to use... But, even then, I am feeling highly discouraged by the answer given here.

On the note of the bug @Sorikairox - you could maybe also try spinning up your own instance of https://esm.sh/ and seeing if using that to bundle your packages with the target=deno parameter could address the problem you're facing, with using the existing bundle command. I too, ran into a similar issue with AWS SDK, but managed to work around it thanks to esm.sh.

I wish you best of luck. This reminds me of another issue that is associated to this specific module - denoland/deno#15015, it seems like there's some instability regarding binding to a wasm context. One can't help but wonder if this is a race condition that's being triggered.

[yacinehmito]

@Sorikairox Neither deno bundle nor deno_emit will work when using a node specifier. This is to be implemented. I don't personally have a use case for it as I never use node specifiers, so I will most likely not implement this.

@dsherret I suggest to rename this issue "Support node specifier" as this is most likely the cause of the error.

[Sorikairox]

@yacinehmito Any way I could help tackling this issue ?
It's a really blocking issue, I am ready to try to work on it despite my limited rust knowledge.

If you have any hint, any guess, that would be very valuable

[yacinehmito]

My point is that an important feature is being deprecated without a fully suitable replacement.

The responsible thing to do is not to deprecate when a fully suitable replacement exists, but as soon as the maintainers know that the feature will be removed. Otherwise, people build things on top of it without the knowledge that it will eventually stop being supported. As I already stated, deno bundle still exists, and it does exactly what you want. Nothing has been taken away from Deno users by deprecating deno bundle. The good thing with the deprecation is that people will try deno_emit first and deno bundle second, which provides valuable feedback about what doesn't work yet with deno_emit, so we can improve it until it is on par with deno bundle.

Deno 2.0 is on the horizon, so I don't really agree with your stance. To my understanding, the bundle command is on its way out officially with 2.0.

I have not found anything that suggests this. I have asked on the Discord whether this would be case, but I doubt they will remove deno bundle until deno_emit is in a satisfying state, for the exact reasons that you have laid out.

[Sorikairox]

Guess I need to find which dependency uses node and get rid of it then. I don't want to use them either.

[whaaaley]

Same here. I'm trying to use the "natural" npm package in deno deploy but it's been a nightmare. The npm specifiers work fine locally, but they're not supported in deploy. So I'm trying to find a way to bundle locally and upload manually. But I get this error. And deno bundle doesn't support npm/node specifiers either.

I guess I'm just out of luck?

[yacinehmito]

@whaaaley From my experience, it is a bit early to be fully relying on npm specifiers and package.json with Deno. The logic at the moment is confined to the CLI. None of the underlying dependencies like deno_graph, deno_cache and such support them (as far as I am aware), which is why it doesn't work on Deploy nor on deno_emit.

[whaaaley]

@yacinehmito Yeah I agree and I do understand. Nice to see some specifics as to why. For me at least it's unfortunate because Natural doesn't work with esm.sh for a handful of reasons, it seems. So I'm kind of stuck. I might have to host somewhere else until that feature is available in deploy or deno_emit .

[yacinehmito]

Natural doesn't work with esm.sh for a handful of reasons, it seems

Happy to help about this on the Discord, if you want. Just ping me.