Make Dino.bundle() work like dino bundle?

[sethp]

This admittedly falls at least a little into the "I'm holding it wrong" category of use-cases, but in trying to see what it would be like to turn dino into a quick-and-dirty dev bundler I found that dino bundle can handle two things that Dino.bundle() won't:

1. Import maps
2. Dynamic imports

This change would bring the two closer together in terms of capability, if that's desirable.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[sethp]

Thanks to @rudoi for helping me figure out how to get the Windows test working in 2ed4a1e!

[kitsonk]

Ref #4752

I am not sure that we want to inherit the CLI's import-map instead of allowing one to be passed to the bundle. As it stands it is an improvement over the existing behaviour though.

When you say it doesn't support dynamic imports, what do you mean? This PR doesn't seem to address that as all if there is an issue there.

[bartlomieju]

Ref #4752

I am not sure that we want to inherit the CLI's import-map instead of allowing one to be passed to the bundle. As it stands it is an improvement over the existing behaviour though.

Agreed, that should be passed as an option in 3rd argument.

When you say it doesn't support dynamic imports, what do you mean? This PR doesn't seem to address that as all if there is an issue there.

deno bundle analyzes and fetches dynamic imports that can be recognized during compile time. I think it's been changed in this PR, as it's only a single switch on ModuleGraph.

[kitsonk]

Agreed, that should be passed as an option in 3rd argument.

Urrr... better to have an options bag... but still better to not take the change until we refactor in #4752 IMO.

deno bundle analyzes and fetches dynamic imports that can be recognized during compile time. I think it's been changed in this PR, as it's only a single switch on ModuleGraph.

👍

[sethp]

Sounds like the consensus is:

1. We'd like to expose options for Deno.bundle() so it could be made to work like deno bundle, but
2. The runtime compiler APIs are planned to undergo a major redesign, and it doesn't make sense to put too much more into the current API in light of that.

Is that right? If so, it probably makes the most sense to close this PR and continue in #4752.

[bartlomieju]

@sethp thanks for the work on this PR, but I'm gonna close it without merge. We're in the middle of big compiler refactor in #6894 which will change a lot of APIs. We can revisit the topic afterwards.