Turning off Strict Mode in Angular?
Solution 1
Following Angular doc, the strict mode can be disabled turning off these flags on tsconfig.json file:
"forceConsistentCasingInFileNames": false,
"strict": false,
"noImplicitReturns": false,
"noFallthroughCasesInSwitch": false,
...
"angularCompilerOptions": {
"strictInjectionParameters": false,
"strictInputAccessModifiers": false,
"strictTemplates": false
}
Solution 2
If anybody runs into this question, I had a similar issue after upgrading from Angular 8 to Angular 10. I had to remove all angular compiler flags, and used the following TS flags:
On tsconfig.json:
"compilerOptions": {
"outDir": "./dist/out-tsc",
"sourceMap": true,
"declaration": false,
"experimentalDecorators": true,
"module": "es2020",
"moduleResolution": "node",
"importHelpers": true,
"target": "es2015",
"noImplicitUseStrict": true,
"resolveJsonModule": true,
"skipLibCheck": true,
"typeRoots": [
"node_modules/@types"
],
"lib": [
"es2018",
"dom"
]
}
On angular.json
{
"$schema": "./node_modules/@angular/cli/lib/config/schema.json",
"version": 1,
"newProjectRoot": "projects",
"projects": {
"my-project-name": {
"projectType": "application",
"schematics": {
"@schematics/angular:application": {
"strict": false
}
}
}
}
}
Solution 3
Most of the time as a beginner in angular framework, the problem which you gonna be face of will be the strictPropertyInitialization options which is set to true as a default
Two of the flags that will have the biggest impact on your development process are strictPropertyInitialization and strictNullChecks. read more...
So you can use --strict
option se to false to create a new angular project without strict mode enabled.
ng new app --strict=false
This will result into tsconfig.json without strict...
options.
Solution 4
Removed the "strict": true
from tsconfig.json
Related videos on Youtube
Ole
Updated on February 08, 2022Comments
-
Ole about 2 years
I'm running into this issue and I'd like to turn off strict mode to get around it.
I've modified
tsconfig.json
with:"compilerOptions": { "strict": false,
And also tried:
"compilerOptions": { "noImplicitUseStrict": true,
But no love. Thoughts?
-
Ole over 4 yearsJust did: github.com/fireflysemantics/is
-
Ole over 4 yearsStill - Would be nice to know how to turn off strict mode because sometimes it's a little too strict ...
-
jfriend00 over 4 yearsIt's not too strict. It's preventing things that are not recommended and there are better ways to code. Seriously, it's best to stay in the habit of coding to strict mode and fixing code when it has problems in strict mode.
-
jfriend00 over 4 yearsI don't know what that github link in your comment means.
-
Ole over 4 yearsThat's the library that's been fixed.
-
Ole over 4 yearsBut in this case it was a little too strict. It's not a big deal to access
arguments.callee.name
you just have to be aware of the edge cases. -
denns over 3 yearswhile you might be right @jfriend00 most examples ins libraries and components are non-strict. So examples won't work in your app, you need to make them strict first. And so far i did not find a best practise guide that solves all of those problems. Although I am totally with you fixing the code instead of ignoring bad practices.
-
denns over 3 yearsmedium.com/lacolaco-blog/… well this article helped me a lot!
-
jfriend00 over 3 years@dennis - Well, I would probably not use a library that required sloppy mode. That's a sign of poor or lazy coding practices IMO. Among many other problems, It's so easy to make trivial mistakes like forgetting to declare a variable in the proper scope and now you have an accidental global variable that can conflict with other code really easily. You can also run linters on your code to identify issues too.
-
challamzinniagroup almost 3 years@jfriend00 Responding with "What you're trying to do is bad" is not an response. It is also not helpful in any way. You do not, nor can you possibly, be aware of all use-cases. A better way to convey your opinion on the matter would be to post an answer, give the answer, and then explain why it is a bad idea in your opinion.
-
jfriend00 almost 3 years@challamzinniagroup - I have no idea where you think I say "what you're trying to do is bad". I expressed a personal opinion that I would not use a library that required my code to use sloppy mode. That's my opinion. I stand by it. I think it's an opinion worth sharing and worth encouraging others to follow. That and my other comments are attempting to educate the OP on benefits of NOT using sloppy mode. This opinion does not belong in an answer as it doesn't answer the question by itself - it's advice on the direction a solution should take.
-
challamzinniagroup almost 3 years@jfriend00 This is a Q&A forum. A question was asked. You did not offer any answer at all. I never said your opinion was not valid; only that is was an opinion that is wildly presumptive based on the almost nothing you know from the OP about the use-case and scenario involved. There are quite probably a number of valid reasons to need to run under what you call "sloppy mode". Just because you can't think of them off the top of your head does not mean they aren't there.
-
jfriend00 almost 3 years@challamzinniagroup - I stand by all my comments here. My first comment suggests that a good path to explore you would be to fix the code so it can run in strict mode. How is that not a valid comment? There are no good reasons to write code that requires sloppy mode. Yes, there could be situations where you require some library that has a sloppy mode design that is just too much work to fix that issue, but that still doesn't mean that you don't first ask yourself if you can get rid of the sloppy mode requirement. IMO, that should always be the first approach. Avoid sloppy mode if you can.
-
challamzinniagroup almost 3 years@jfriend00 And you've finally hit the nail on the head.This is a much more complete comment that is not assuming in nature.That's all my point was here - that you simply replied and said "don't do it. fix your code". That's simply not helpful. Now, you've said "I don't recommend you do it, because {insert reason(s) here}. But I also acknowledge there may be edge cases where you simply have no choice.
-
challamzinniagroup almost 3 years... and for the record - I completely agree with you on this. Strict mode should always be the default go-to; and only when there is a compelling reason why you can't, should you not.
-
-
d0rf47 almost 3 yearshey so i did all of that and i am still getting the error in my editor. I don't know what else to try. I am using angular 11.0.9 any other ideas?