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

// 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

About this issue

Original URL
State: closed
Created 4 years ago
Reactions: 4
Comments: 18 (7 by maintainers)

Most upvoted comments

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?

+49

Dan503 on Jan 26, 2020

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.

+15

Dan503 on Jan 26, 2020

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.

David-Else on Jan 28, 2020

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.

kitsonk on Jan 28, 2020

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.

artisonian on Jan 27, 2020

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

Soremwar on May 8, 2020

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.

artisonian on Jan 26, 2020

@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.

nayeemrmn on Jan 27, 2020