No, makes no sense imo. If we can import and what is already v. complicated because the package managers (pnmp) are kinda pushing this onto the user, that’ll raise it as an issue here in any case. TS can still make breaking changes, so does @types/* do often enough that we can’t avoid it.

The generated routes.ts file imports from @tsoa/cli. These services would need to be moved from @tsoa/cli to @tsoa/runtime before @tsoa/cli could be removed from production. https://github.com/lukeautry/tsoa/blob/118f090981f90078b348987cad7a3ae65a5c8d3a/packages/cli/src/routeGeneration/templates/express/express.hbs#L5

On further investigating this issue, I think there is a fundamental problem with the package tsoa. It has a dependency on the cli and on the runtime. One of these should be a regular dependency (runtime) and the other a dev dependency (cli). However, when you install package tsoa as described in the “Gettting Started” instructions, both of these packages become regular dependencies. Furthermore the newer version of the cli has the missing @hapi/boom issue.

And here is how you can resolve this issue while also avoiding the bug reported at the beginning of this discussion:

Everybody who follows the “Getting Started” instructions at https://tsoa-community.github.io/docs/getting-started.html will add package tsoa to their project. As a result all of them will have the cli as a runtime dependency!

I ran this little experiment:

1. Remove package tsoa
2. Add package @tsoa/runtime as a regular dependency
3. Add package @tsoa/cli as a devDependency
4. Replace imports of tsoa with imports from @tsoa/runtime

Then clear your npm cache, delete node_modules, lock file, etc. to start with a clean slate. Restore packages, build and run your tests.

With this setup I managed to change the cli to a dev dependency. Also, this resolves the missing @hapy/boom issue for both, version 6.0.1 and 6.1.0 of tsoa (which as a single package I no longer use at the moment).

So I am wondering if this may be the best way to resolve this issue:

• clearly separating between the runtime and the dev tools by using two different packages, namely the runtime and the cli instead of a aggregate package named tsoa.

This has the additional advantage that everybody should be able to remove the cli from their production deployments.

Again, happy to stand corrected in case I overlooked something. So far, I have applied this solution to two repositories and so far there don’t seem to be unwanted side effects.

As a point of reference, the dependencies in my pnpm-lock.json file look as follows:

   /@tsoa/cli@6.1.0:
    resolution: {integrity: sha512-fAYdR03L5bI44tz5zH0FiJUcQgnntF6fXtWfUxQf3AhuN/z4R6j2XEET8fwe0ABs7skD9a/98hqUggvKNCsIDg==}
    engines: {node: '>=18.0.0', yarn: '>=1.9.4'}
    hasBin: true
    dependencies:
      '@tsoa/runtime': 6.1.0
      '@types/multer': 1.4.11
      fs-extra: 11.2.0
      glob: 10.3.10
      handlebars: 4.7.8
      merge-anything: 5.1.7
      minimatch: 9.0.3
      ts-deepmerge: 7.0.0
      typescript: 5.4.2
      validator: 13.11.0
      yamljs: 0.3.0
      yargs: 17.7.2
    dev: true

  /@tsoa/runtime@6.1.0:
    resolution: {integrity: sha512-ZE+VMrzVV0laFjUm0j7+ox7VG0yMOiQcouCE4LdS335jMc/pA0hbcxl9EoKexTyfWgmMMFjstvQVBiAq5y60Vw==}
    engines: {node: '>=18.0.0', yarn: '>=1.9.4'}
    dependencies:
      '@types/multer': 1.4.11
      reflect-metadata: 0.2.1
      validator: 13.11.0

As desired, the cli is a dev dependency while the runtime is a regular dependency. Also, the cli has the runtime as a dependency which makes a lot of sense.

FYI @ManfredLange the text you wanted to provide in the copyable boxes appears to be empty.

I also encountered this today though and downgraded back to 6.0.1. Another issue besides being broken even in developent (due to @hapi/boom missing as I am using Koa) is that we now need @tsoa/cli as production dependency. The generated routes now import the Template stuff from @tsoa/cli Could we revert this? I would like to keep @tsoa/cli as a devDependency