Hello 👋
I opened an issue (#1630) a couple of days ago and found some time today to open this PR.
The CLI is a CJS package, so all modules it imports must be CJS. tsoa configs are located outside the CLI, potentially in an ESM package. To force these configs to be treated as CJS, they need to have the .cjs extension and the CLI must accept them.
Closes #1630.
All Submissions:
[x] Have you followed the guidelines in our Contributing document?
[x] Have you checked to ensure there aren't other open Pull Requests for the same update/change?
[ ] Have you written unit tests? I did not find any tests specifically for getConfig or resolveConfig. There is config.spec.ts, but it's just tests for resolved configs. Let me know if I missed something.
[ ] Have you written unit tests that cover the negative cases (i.e.: if bad data is submitted, does the library respond properly)?
[x] This PR is associated with an existing issue? #1630.
Closing issues
closes #1630
Potential Problems With The Approach
None I can think of. In the long run, I think it's worth considering to move the CLI package to ESM.
Hey @WoH, thanks for having a look! I see you ran the pipeline and it seems to me that two jobs failed because yarn install failed or was too slow.
Would you mind restarting to give it another try?
Hello 👋 I opened an issue (#1630) a couple of days ago and found some time today to open this PR.
The CLI is a CJS package, so all modules it imports must be CJS. tsoa configs are located outside the CLI, potentially in an ESM package. To force these configs to be treated as CJS, they need to have the .cjs extension and the CLI must accept them.
Closes #1630.
All Submissions:
getConfig
orresolveConfig
. There isconfig.spec.ts
, but it's just tests for resolved configs. Let me know if I missed something.Closing issues
closes #1630
Potential Problems With The Approach
None I can think of. In the long run, I think it's worth considering to move the CLI package to ESM.
Test plan