Deno: `deno bundle` does not support tsconfig.json

[Dan503]

// bundle.ts

// @ts-ignore
import { hello } from './hello.ts'
// @ts-ignore
import { button } from './button.ts'

document.addEventListener('DOMContentLoaded', () => {
    hello()
    button()
})

deno bundle bundle.ts bundle.js

error TS2584: Cannot find name 'document'. Do you need to change your target library? Try changing the `lib` compiler option to include 'dom'.

So I add a tsconfig.json to the root of the project:

{
    "compilerOptions": {
        "strict": true,
        "lib": ["ES2019", "dom"]
    }
}

I still get the same error:

error TS2584: Cannot find name 'document'. Do you need to change your target library? Try changing the `lib` compiler option to include 'dom'.

I go searching for an answer and based on this merged pull request it looks like I need to add --config tsconfig.json to the command.

deno bundle bundle.ts bundle.js --config tsconfig.json

error: Found argument '--config' which wasn't expected, or isn't valid in this context

Deno version: 0.31.0

[artisonian]

I ran into this issue as well while trying to bundle a file with decorators. The CLI flags got cleaned up in #3365, so I'm not sure if removing config for bundling was an oversight.

[nayeemrmn]

deno bundle isn't for browser code! It's just for bundling your Deno runtime code into a single JS file. It is an issue that deno bundle doesn't support this flag, but compilerOptions.lib gets ignored either way. See https://gitter.im/denolife/Lobby?at=5e262261c319b638aa582623.

[Dan503]

deno bundle isn't for browser code!

Why not? It seems pretty reasonable for someone to want to create a bundled version of their browser based JS code by just running deno bundle.

[nayeemrmn]

See #3726. This would allow one to easily create a userland module which acts as a compiler for browser code. This functionality shouldn't be explicitly be built-in. One awkward subcommand which has anything to do with frontend code, while no other does, wouldn't be reasonable.

[Dan503]

Maybe think of it this way.

The web dev community have browserify, rollup, and webpack. All of these are essentially JS code bundlers for bundling front end code.

Now Deno comes along and says "hey look everyone! We have code bundling built directly into the system. No plugins required!"

Everyone goes and tries to use Deno to bundle their front end JavaScript just like how they have been using every single other code bundler before Deno. Then quickly everyone hits a brick wall when Deno says it doesn't understand browser code.

You can see how this is just confusing and annoying for people right?

[nayeemrmn]

@Dan503 If I did randomly assume that the bundle command on this runtime meant bundling for some other runtime, I would be annoyed at myself, sure.

But the issue of whether or not to have this feature is discussed starting here https://github.com/denoland/deno/issues/2475#issuecomment-526993668. The gist of it is that a "good" bundler does a _lot_ more than what is already given here. It doesn't make any sense to build that into a server runtime that tries to be minimal. There's no problem with having to import one.

[artisonian]

Even so, my issue was not being able to enable experimental decorators, which is still valid if you want to distribute a bundle without requiring someone else to add a tsconfig.json.

[kitsonk]

It should support tsconfig.json, but just like deno run it will always ignore the lib library.

For bundling for a browser, you want to use Deno.bundle() with #3726 being delivered.

[David-Else]

I think @Dan503 is correct, his described case scenario happened to me.

@nayeemrmn

If I did randomly assume that the bundle command on this runtime meant bundling for some other runtime, I would be annoyed at myself, sure.

I never assumed that Deno would only bundle for it's own run time, maybe that was naive, but I am sure I will not be the only person to think that. When you say 'some other run time', there really only is deno, node and the browser in the mainstream. Node can be considered legacy, so that leaves only two run times remaining.

I would ask the Deno developers to consider that the vast majority of use for JS/TS is actually frontend browser code. Backend programming is minority interest. Most people install and use Node to run build tools and access NPM. Deno is a golden opportunity to interrupt this ancient and crufty practice and usher in a new era of simplicity and ease of use for the entire JS/TS community.

Default ES Modules and getting rid of NPM is a revolution that would benefit everyone, not just back end coders.

I am really hoping that Deno will evolve into a one stop shop for all JS/TS developers. One command line program that can compile, test, lint and format your code for the browser and itself. It can almost do that already. I appreciate that this might be a side goal for developers, but the opportunity to help so many people and move things forward should be seriously considered.

It would make little difference if browser compatibility was done in the standard library or built in, just so long as it worked out of the box and was fully supported.

https://github.com/denoland/deno/issues/3726 looks fantastic, but please make sure its features are accessible out the box using the standard library. A new browser bundler could be included there, tree shaking etc could be added later.

[kitsonk]

I think there are a few points...

Treating "browser" as a single runtime is folly. While the evergreen browsers are adopting most features quite quickly, there are still quite a few gaps. Once you add in needing to target mobile browsers and IE11 (a reality for a lot of corporate environments), you now have a really uneven landscape still. It is far from a single runtime. The web platform is complicated, far more than just compliance with ECMAScript. It contains loads and loads and loads of APIs plus loads of other technologies (CSS, HTML, SVG, WebGL, WASM, WASI, etc.).

Node.js being "legacy" is also a folly at this point. Even if Deno is super successful, and "replaces" Node.js, it would be a long long long road. Dismissing it, and its ability to continue to evolve is folly as well.

I think the perspective that most development is "front end" in JavaScript is related to where individuals sit. My personal experience is there is loads and loads of JavaScript in the backend. I don't think non-frontend development is a minority interest at all.

@ry and I chatted about this in general yesterday, what I think the outcome of the conversation was:

• deno bundle like deno run like deno fetch like deno test is for making developing workloads the run in Deno easier/better/etc. They are opinionated, and will always will be. They are the "back box". Just because some deno bundle outputs can be imported into a browser is a side-effect, and not something end users should couple to.
• The workflow of building a web applications in a low friction, low configuration way is a great use case for Deno and something that should "just work". That should take the form though of something that is opt in, and part of the standard library... so something like deno https://deno.land/std/build/react.ts ./index.ts, were the output would take into consideration that it will run in a browser (and not under Deno, therefore no Deno namespace) as well as do the other things that need to be done to have a valid bundle.

3726 is part of that solution, but I will also work on adding stuff to std as a starting point of building out a more robust solution that the community can help with to accomodate front-end dev workflows.

[Soremwar]

I have always tought of deno bundle that way.

There is a need for a browser-oriented bundle yeah, but the workload of all that functionality should be directed as a side-tool, and not a main goal of the project.

Deno provides a set of tools that Node lacks or treats vaguely that were in many case solved by the community supporting Node, as is the case of Webpack, Prettier, ESLint (well maybe not that much) and make BackEnd development less of a hassle. However that makes Node much more of an empty shell, since must-have features are out of the reach if you only installed node and start programming with it. That has lead people to confuse between core functionality and plugins made to increase its reach in the Node environment.

Deno's main function is to complement JS native lacks in the backend area much like Rust does (Lots of Deno toolset philosophy is based on Cargo, or at least it seems so).

So even though Deno supports JSX you wouldn't expect it to have React integrated in it would you? Or a compatibility module with Node embedded in the code.

That would be extras, since they go beyond the reach of the project, and are itself a large set of tools that requires to be mantained constantly.

Webpack and Babel polyfill have been under constant development and improvement for years now, since legacy and not clear JS version system are such a delicate matter, so yes I would greatly prefer if they kept apart from the main Deno core.

[alshdavid]

I feel it makes sense that compiling requires a target architecture. The arch type corresponding to a different transformer.

That way transformers can be created in user space and added to deno.

Say

deno bundle --arch=browser --type=esm
deno bundle --arch=browser --type=umd
deno bundle --arch=deno
deno bundle --arch=wasm

But it takes into consideration the tsconfig.json

As an unrelated side note, please resolve path transformations in both the emitted js and d.ts files. Oh my god writing a TS library with absolute paths is impossible.

[kitsonk]

@alshdavid this type of flexibility is what Deno.bundle() API is for.

[Dan503]

I see the merge. It looks like you still have to write this though:

deno bundle bundle.ts --config tsconfig.json

In order to compile using tsconfig.json, you should only have to write this: (and have tsconfig.json in the root folder)

deno bundle bundle.ts

[kitsonk]

@Dan503 we are always explicit about things in Deno. We will not automatically resolve tsconfig.json (or any other external file).

[Soremwar]

@Dan503 As kitsonk pointed out, Deno wont resolve any kind of metadata unless you specify it to do so

Don't see it as a disavantage though, since you are actually freeing yourself from compiler assumptions and have options to do things such as multiple tsconfig in a folder for different purposes

They don't even need to be named tsconfig to be resolved by Deno

[Dan503]

I was expecting that it would default to using tsconfig.json like every other tool out there and you can explicitly define a different config using:

--config something-else.json

[Soremwar]

@Dan503 Those are Node tools. Deno phylosophy aims to be as straight forward as possible, so...no unnecessary abstractions