Hello 
I just installed Strapi v4.3 to try Typescript with this command:
npx create-strapi-app@latest --typescript strapi-with-ts
Everything seems to work fine, but if I have a Typescript error, the app just doesn’t want to compile, pointing me to the typescript error.
I don’t want this behaviour, I want it to compile and run anyways, independent of Typescript complaining.
I already tried:
"compilerOptions": {
"strict": false,
...
},
in the tsconfig.json file but it didn’t change anything.
Any help would be welcomed, thanks!
Hello there 
The whole point in using typescript is to catch bugs & errors before or at last during compilation. You should not ignore typescript errors.
You can not ignore every typescript error, but some can be ignored (e.g. strict type checking like in your example). Please post your exact error message here, so we can help you resolve the issue.
1 Like
Is not a big problem, I will just fix the code in this case.
But I would like the option to turn it off, one of the fundamental principals of Typescript is incremental adoption. A warning at compilation should be an option, because I rather have a warning of something that I made wrong than just changing from .ts to .js and never see the error again.
For example: the documentaion on how to deploy it to Heroku has a problem with database.ts, it does not compile:
Starting the compilation for TypeScript files in /tmp/build_33a462b5
config/env/production/database.ts:3:47 - error TS1005: ';' expected.
3 import parse = require('pg-connection-string').parse;
~
config/env/production/database.ts:4:16 - error TS2349: This expression is not callable.
Type 'typeof import("/tmp/build_33a462b5/node_modules/pg-connection-string/index")' has no call signatures.
4 const config = parse(process.env.DATABASE_URL);
~~~~~
Found 2 error(s).
Is a copy and paste from the documentation, and I don’t feel like diving into it right now, so I just switched to database.js and the error is gone for ever. I would have like to leave the warning on.
Sometimes you will deal with external factors that you can’t control (like third party dependencies), and not being able to build your app because some parameter can be null even thought you know that is totally fine seems like a radical approach.
And now consider that I have an already existing app that has 3 years and that I have to migrate, here is when incremental adoption becomes a deal breaker.
Sorry to sound a bit pissed off, I have been changing gradually all the .js to .ts because if not the app doesn’t work, I was expecting a softer landing, but now that I’m already half way I will just try to finish it.
Outside of that I’m so daim happy that Typescript finally arrived to Strapi, that is why I’m starting the migration now even if the documentation says that I shuldn’t do it right now.
As far as third party dependencies goes, you can ignore library checks. In your tsconfig.json, set compilerOptions.skipLibCheck: false.
The default behavior of the typescript compiler is (compilerOptions.noEmitOnError: false ), to produce .js output even if non serious errors occur.
Serious errors can not be ignored, because they may prevent the compiler from correctly interpreting your code.
2 Likes
The whole point in using typescript is to catch bugs & errors before or at last during compilation . You should not ignore typescript errors .
While I completely agree with this statement, there are scenarios where it’s just not controllable by you, especially when working with 3rd party libs. In addition to the workarounds mentioned already in this thread, you can also add a // @ts-ignore comment above the problematic line to make TypeScript ignore any errors with this line, or add a // @ts-nocheck comment on top of the file to turn off any TypeScript checks for this file completely.
I must warn you, this can be considered bad practice as you basically undermine what TypeScript is made for.
2 Likes
With already a couple of days in, I think I know what really bothers me: the fact that it kills the server and refuses to compile while in development mode.
Being strict in production makes sense. But in dev is annoying, I realized that I save multiple times my files just for the linter to clean up my code, which is really useful, and I’m far from the only one on doing that.
So I can’t save and lint my files without worrying that I will crash my server and I have to go back to turn it on. Which happens all the time.
Conclusion: I would like it to throw errors in production, but warnings in development
1 Like