Mod File Generation

[harrysolovay]

This may be out of scope, but I believe it's enough of a productivity boon that I'd like to propose it just incase.

I frequently utilize a tool called moderate to regenerate mod.ts files. The workflow is very simple:

1. whenever I create a mod.ts that I'd like to "moderate", I add a // moderate comment at the very top.
2. whenever I wish to regenerate the file, I run a command deno task mod, which writes re-export statements for all files and mod.ts-containing subdirectories.

One can even specify excludes in the directive + add leading statements to be left untouched before the // moderate directive. Ie.

export { SomethingElse } from "./something_else.ts"

// moderate --exclude something_else.ts

export * from "./file.ts"
export * from "./dir/mod.ts"

This utility saves me significant time.

I was wondering if anyone thought a workflow such as this could make it into Deno toolchain, where it could be standardized and made to benefit the broader ecosystem. Dealing with mod/barrel files / and reexport statements is just such a pain for so many developers. I think we can do better by making this or a similar workflow a first class citizen.

[BlackAsLight]

So it just takes all your files and re-exports them in a mod.ts file? How does this save significant time? Why would you need to regenerate them and not update it whenever you create or delete a file? Since you've essentially switched it from manually including to manually excluding, I don't see how it saves any time.

[harrysolovay]

It's easy to forget to add/remove/update reexports. Consider projects that have dozens of files and many contributors.

Also: auto-import updates come to mind: they often result in mod files that contain undesirable reexports. For instance, let's say we have a mod.ts that looks as follows.

a/b/mod.ts

export * from "./c.ts

If we move c.ts into the parent directory (aka. it will be at a/c.ts), the mod.ts may auto-update to the following.

export * from "../c.ts"

Moderate ensures that this reexport is no longer in a/b/mod.ts, and ensures that it present in a/mod.ts.

"moderating" is a way to simplify managing exports in large projects. The Deno team already somewhat "moderates" denoland/std. Although it's manual, there is an agreed upon convention for organizing and excluding files from different subpackages/mods.

I'm not suggesting a specific // moderate directive, nor approach to generating mod files, but rather that mod file generation / convention-checking is useful and may merit consideration in the Deno toolchain itself.

[marvinhagemeister]

This sounds like a useful features for certain projects, but I'm not sure if putting that into Deno itself is the ideal place. Personally, I haven't encountered projects where everything of the sibling files should be exported. There is always an exception here or there which makes automating it more tricky. That said it's a perfect feature to put into a tool on jsr.io and share it across your projects that way. That's something you can do today and don't need to wait for Deno to add something.

[harrysolovay]

I would agree if not for the possibility that a proper solution may utilize the Deno module graph (to prevent issues such as used-before-initialization, misc).