Why deps.ts and mod.ts is BAD in Deno

If you read the official Deno manual, you'll notice that the author advices you to contain all dependecies into one file.

Similarly, if you're creating a library, the de-facto standard is to export all modules in a single mod.ts file.

Somehow, this convention is suppose to make the development experiences better.

But instead, let me tell you why this convention is doing the opposite, which is making the development experience worse by increasing compile time (around 200% based on my simple benchmark).

If you want to look at benchmarks, check it out at this repository.

Imagine we have a deps.ts:

export {A} from 'https://deno.land/x/a/mod.ts'
export {B} from 'https://deno.land/x/b/mod.ts'

And a main.ts file:

import {A} from './deps.ts'

By running deno run main.ts, Deno will actually also resolve dependencies of B and typecheck thems even if main.ts don't really need them, imagine B also imports from its own deps.ts, and so on and so forth.

Ultimately, most of the compile time is wasted on compiling unused imports.

Moreover, if you try to bundle it by doing deno bundle main.ts, you'll notice that the bundle output also contain B and its dependencies because Deno do not support tree shaking.

So how can this problem be solved? Easy, just use direct URL imports! By doing so, you will have improved compile time and improved bundle size.

// main.ts
import {A} from 'https://deno.land/x/a/mod.ts'

These are all the problems we have when we are using npm.

You can find Ryan Dhal, the creator of Deno talking about this problem here.
Do you remember that when you tries to import a Lodash function into your code and suddenly the bundle size got so huge?

So how the Lodash community solves this? They do it by publishing a package for each function.

Therefore if we want to avoid:

• unnecessary long compile time
• unnecessary huge bundle size
• Deno packages collapsing into a black hole.

The whole Deno community needs to stop placing all dependencies/export into one deps.ts/mod.ts file.

If we continue to use deps.ts and mod.ts, we will hinder the development experience of Deno developers by wasting their precious time waiting to compile unused dependencies.

Here's what I propose for managing dependancies, so instead of putting every dependencies in single deps.ts like this

// deps.ts
export {A} from 'https://deno.land/x/a/mod.ts'
export {B} from 'https://deno.land/x/b/mod.ts'

Export each of them as separate files under the deps folder.

// deps/a.ts
export {A} from 'https://deno.land/x/a/mod.ts'

// deps/b.ts
export {B} from 'https://deno.land/x/b/mod.ts'

Ok, without mod.ts how do we allow library users to discover API easily?
Simple, instead of placing all export into a single mod.ts, split them into separate files under the mod folder.

For example, instead of having:

// mod.ts
export {A} from './a.ts'
export {B} from './b.ts'

Do:

// mod/a.ts
export {A} from '../src/a.ts'

// mod/b.ts
export {B} from '../src/b.ts'

Last but not least, if the whole Deno community ditch this deps.ts/mod.ts practice, Deno by itself might not even need to implement tree-shaking and skip-unused-import features (which is tremendously difficult to implement).

It's like how social distancing prevented the spread of Corona virus instead of relying on vaccine.

Please if you think this article make sense, and for the greater good of Deno's future, please share it with your fellow Deno developers.