Deprecate "deno bundle"

[ry]

JS bundlers have a lot of complexity and we do not want to take on all that complexity in Deno. We believe this can be done effectively in "user space" - that is, it doesn't need to be built into the Deno executable. Packup is an example of a Deno program which utilizes esbuild-wasm to provide complex bundling abilities.

Ultimately we'd like to remove swc_bundler dependency completely completely from Deno.

[bartlomieju]

If we were to do that, then deno compile couldn't work (or would require significant changes to keep the functionality working).

[MierenManz]

I can see why it is done because there are alot of bundler's that already provide the same or more than deno bundle

Other than that, I'm fine with deprecating it and eventually removing it eventho it feels a bit weird to remove a handy utility like this with the only reason being "it can be done effectively in user space"

[LionC]

I personally will always vote for making deno more of a pit of success for things that will predictably be needed by a huge percentage of apps. Keeping out parts of a toolchain that is needed for a lot of projects makes people spend time on choices that will likely not generate a lot of value, making project setup more complex and the whole space more fragmented.

At least how I see it, deno tries to solve exactly that go style by having one toolchain to do things and let people write applications instead of tooling setup.

[ry]

If we were to do that, then deno compile couldn't work (or would require significant changes to keep the functionality working).

@bartlomieju To clarify (for other people) "deno bundle" can be deprecated and removed without effecting "deno compile", but in order to remove the swc_bundler dependency, we'd need to do some work to "deno compile" maybe to use something like the eszip json file format instead.

[caspervonb]

JS bundlers have a lot of complexity and we do not want to take on all that complexity in Deno. We believe this can be done effectively in "user space" - that is, it doesn't need to be built into the Deno executable.

While true, that can be said for nearly all of our subcommands.

I'm against just because we're taking away a useful (albeit, needs some tic) feature from our promise of being a one stop toolchain.

[sebastienfilion]

My first reaction was “no”. Then I thought about it a little bit and still “no”.
From where I stand, one of the big promise of Deno was the out-of-box toolchain. If we start removing every tools because there might be another option in user land, what’s the argument to not remove everything?
I think that we’re better off with a “not as great” bundler than no bundler; at least a “not so great” bundler can be fixed or improved. 🤔

[dsherret]

JS bundlers have a lot of complexity and we do not want to take on all that complexity in Deno. We believe this can be done effectively in "user space" - that is, it doesn't need to be built into the Deno executable.

While true, that can be said for nearly all of our subcommands.

I'm against just because we're taking away a useful (albeit, needs some tic) feature from our promise of being a one stop toolchain.

If we start removing every tools because there might be another option in user land, what’s the argument to not remove everything?

I think the main difference here is that deno fmt & deno lint are used to help with the development of JS/TS that gets executed by deno. deno bundle however is mostly used for packaging up a single script for using it in the browser, to help target other runtimes, and perhaps as a way to distribute a library for Deno as well (less files, so less requests, though that's more of a nice to have).

On the note about complexity, I believe userland already has and will be able to provide better versioned APIs that aren't tied to the deno executable in order to solve this problem. They'll be able to provide features like code splitting, transforms, and such that would be unreasonable to add to deno bundle.

[LionC]

I think the main difference here is that deno fmt & deno lint are used to help with the development of JS/TS that gets executed by deno. deno bundle however is mostly used for packaging up a single script for using it in the browser

But Deno explicitly invests work to be as browser compatible as possible, so I do not see how it does not fit - I see more potential to standardize an almost required part of the toolchain that people spend a ridiculous amount of time on right now (choosing one of 6 tools and 6273 meta frameworks that configure them) without writing actual code to solve their actual problem.

On the note about complexity, I believe userland already has and will be able to provide better versioned APIs that aren't tied to the deno executable in order to solve this problem.

Deno's philosophy is to have a one stop toolchain - that does not prevent people from writing userland alternatives but I still do not see how the option of alternatives defeats the purpose of a central standardized toolchain that will see a lot of use because it is convenient.

They'll be able to provide features like code splitting, transforms, and such that would be unreasonable to add to deno bundle.

Why are they unreasonable?

[dsherret]

I'm just saying there's a difference between deno bundle and the other sub commands.

They'll be able to provide features like code splitting, transforms, and such that would be unreasonable to add to deno bundle.

Why are they unreasonable?

For example, implementing transforms would expose a huge amount of API that rapidly changes under the hood. People would be relying on what's available in the deno executable rather than a semantically versioned API. Using a versioned imported module would provide more stability and likely work no matter what version of the deno executable is used (since they're not tied together). For code splitting and more advanced bundler features it would require config or to expand the complexity of Deno.emit (in which case, once the complexity becomes too great I believe it's more appropriate to rely on a versioned imported module so that breaking changes can easily be made by the maintainers).

[wperron]

I'm mixed on this. On the one hand, bundlers are a rabbit hole that doesn't seem to ever end. deno bundle sort of opens the door to endless user requests to support this and that feature. On the other hand, I also agree that one of the selling points of Deno is that it is a one-stop-shop toolchain for the whole developer workflow, and it would be a shame to lose that feature.

We're in an interesting place right now since we're bundling swc in the runtime itself, so while esbuild and swc compiled to wasm are probably fast enough, a truly native solution is most likely faster. I think a sensible course of action would be to remove the deno bundle subcommand but keep Deno.emit in the runtime and keep working on its capabilities. The idea here would be to leave the implementation of the bundling, chunking, code splitting, whatever to userland, but provider the low-level API to access swc directly under the hood so that these tools can be written in JavaScript yet benefit from the native speed.

[mreinstein]

This is really a fascinating discussion! There are a lot of things that come to mind:

• bundlers are a rabbit hole of functionality because they tend to be very general purpose, providing a plugin interface so teams can use whatever tech they want in their build process (pug? sass? babel? 8million other things?)
• I can understand the apprehension around this thing staying in core; it will inevitably balloon in size if we wanted to support all the things.
• I really like that Deno skews torwards minimalistic opinions on several things (you don't need npm, deps.js will suffice mostly, etc.)
• I think Deno's first bundle command attempt stays consistent with this minimalism ethos. <opinion>I'm actively trying to drop all this over-engineered stuff like babel, etc. and get back to a sane, minimal prod build pipeline</opinion>
• from an adoption perspective, I get why Deno would want it's bundler to keep this flexibility. It enables more teams to adopt. (I'm internally debating this at work right now in fact. We have an over-engineered slow build system based on node and I want to move to Deno but we haven't stripped out enough stuff to make that viable yet.)

If Deno is able to articulate a bundling vision much the way it has for other aspects of itself, It may make sense to leave it in core.

To me that would look like taking a minimal stance and saying "sorry, we don't think you should be running 4 different html/css/js transpilers in your build system, etc." We have an ecosystem that has gorged itself on tools. Enough is enough. :)

[kitsonk]

I remember standing on a stage with you Ry at TSConf and stating that "Deno CLI will be the only tool you need" and now you are suggesting backing away from that.

I am not supportive, as it fundamently goes against what I thought we were trying to accomplish. Changing the infrastructure so that there are less issues with deno bundle is one thing, deprecating it is just cruel. Next thing you know, we will be requiring people to load tsc or some other type stripper themselves to use TypeScript with Deno because it makes maintaining Deno easier.

[ry]

I remember standing on a stage with you Ry at TSConf and stating that "Deno CLI will be the only tool you need" and now you are suggesting backing away from that.

@kitsonk Deno CLI is still the only tool you need to do bundling, even if you remove deno bundle. Packup is a good proof of concept:

deno run -A --unstable https://deno.land/x/packup@v0.0.13/cli.ts build index.html

The alternative is that deno bundle starts competing with systems like webpack, esbuild. This is likely a deep rabbit hole of options.