[Feature] External DeepKit CLI for Managing Applications

DeepKit makes CLI commands part of the application so that we can easily add our own commands. This is definitely a great design, but when there is not only a DeepKit application per repository (such as Angular + DeepKit repo or DeepKit monorepo), an external CLI can make things much easier.

The DeepKit CLI should super lightweight. Its reponsibility is just managing applications.

Launching Applications

Like Angular CLI, it has a configuration file deepkit.json generated by the DeepKit CLI when creating new applications.

{
  "applications": {
    "app1": {
      "root": "projects/app1",
      "tsConfig": "projects/app1/tsconfig.app.json"
    },
    "app2": {
      "root": "projects/app2",
      "tsConfig": "projects/app2/tsconfig.app.json"
    },
  },
  "applicationDefault": "app1",
}

Now we can launch our applications using the CLI:

deepkit run server:start // app1 by default
deepkit run server:start -p app2 // shortcut of --project

These are equivalent to:

npx ts-node -P projects/app1/tsconfig.app.json projects/app1/app.ts server:start
npx ts-node -P projects/app2/tsconfig.app.json projects/app2/app.ts server:start

Note that shebang is not possible with the case of multiple applications, as there are usually multiple tsconfigs, especially when the repo contains both frontend and backend projects.

Building Applications

With DeepKit CLI, we have the project roots and tsconfigs specified in the deepkit.json, so we can simply build applications like this:

deepkit build
deepkit build -p app2

These are equivalent to:

tsc -p projects/app1/tsconfig.app.json
tsc -p projects/app2/tsconfig.app.json

Unlike Angular and ts-node having their own CLI entry, currently deepkit relies on ts-node and tsc, which makes us unable to know which tsconfig we are using, so @deepkit/type-compiler can only look for tsconfig by using const tsconfigPath = join(currentDir, 'tsconfig.json').

This makes it impossible for us to customize the path of tsconfig, and also prevents us from using the extends feature of tsconfig. But now the paths of tsconfig are all specified in deepkit.json, we can resolve the correct tsconfig of each project.

[marcj]

I’d really prefer to not introduce yet another build system when its not totally necessary. The issue with @deepkit/type-compiler’s tsconfig.json resolution algorithm can be solved, but is even in its current stage able to support extends feature and multiple projects in the same repo. You just have to put a tsconfig.json inside each sub project folder and don’t rely solely on custom filenames llike tsconfig.app.json. You can though, but you have to put tsconfig.json right next to it, or in an appropriate sub folder. The current flexibility makes it actually easier to have multiple projects in the same repo as you have not to think about or adjust a deepkit specific configuration file in order to set up it. It works naturally with the build tools you already use.

Deepkit’s app framework (@deepkit/app and @deepkit/framework) was explicitly designed to never require a global deepkit CLI tool or any untyped configuration files, to not hide complexity or hide the entry point of your application. There is nothing worse than having to deal with a huge json configuration file like we have in Angular with angular.json and other frameworks. It’s unergonomic, unintuitive, and decreases flexibility. If Deepkit can be used with any build tools out of the box like nx, webpack, etc, then this is a win for me. Requiring to learn yet another build tool and configuration schema in JSON is a huge loss regarding developer experience and flexibility for me.

Unfortunately, I don’t see in this proposal any improvement, but only drawbacks.

[marcj]

It requires every developer to manually make main.ts executable after cloning the repository

Git stores file permissions like the execution bit