Angular-cli: RFC for strict mode or let the opt-in strict mode really strict

[cyrilletuzi]

Hello everyone, and thanks for the hard work.

Unfortunately, today I wake up with despair when discovering #18931, which removes the no-any lint rule in Angular v11 projects generated with the --strict option. Which is a step back from #17834.

While I understand you try to please everyone and that some of the feedback you have may be negative, as an Angular trainer who teach to thousands of developers, I have a very different feedback. So the first thing I ask for is transparency, ie. knowing where your feedback comes from and why (with rational arguments, not just vague feelings like "it is difficult").

Also, I'm asking for consistency. The strict mode has a long and chaotic history in Angular. I won't redo the whole history here, but one example: you asked me in #17834 to add the typedef lint rule in non-strict projects, which can be quite annoying and is questionable when wanting to work in loose mode. So it was making non-strict projects more strict, while now you are making strict projects less strict with #18931.

So for both these reasons, I'm asking you to do a public RFC for the strict mode.

Below I will detail all my rationale.

Strict mode is opt-in and currently hidden

From #18931:

users found it hard to work with the no-any lint rule

Even putting aside that this rationale is questionable (more on that below), the strict mode is currently:

• an opt-in option, meaning nobody is forced to use it,
• a hidden option, meaning that someone using it is choosing voluntarily to do so.

So why people wanting to work in loose mode are using the strict mode at all? And as a consequence, why people wanting to do a good job, ie. in strict mode, should be impacted by the first people?

Why static typing is important

Before, what we did in JavaScript (with tools like jQuery) was very different: we we were just adding a few animations/interactions on a website. So if JavaScript was failing, the website would just not be animated, but would basically work.

Now with tools like Angular, we are doing whole applications. As a consequence, JavaScript is now managing routing and templating, ie. in non-technical terms, navigation from page to page and displaying the pages. So if JavaScript fails, the app is down.

So managing errors in Angular projects is not just a fantasy but a requirement. While not all, a lot of errors comes from the fact that JavaScript has a dynamic typing system. Thus TypeScript.

Why strict typing is important

Issue is: to be compliant with standard JavaScript, TypeScript does not enforce strict mode by default. That means that a lot of code is still subject to errors. Thus TypeScript strict mode.

Note that a project created with tsc --init will be in strict mode by default, as it is the officially recommended way to work in TypeScript. React and Vue projects, when generated with TypeScript option, are also in strict mode by default.

Why really strict typing is important (no-any)

Issue is: TypeScript strict mode is not that strict. It still allows explicit any. Each time you introduce an any, you open the door to errors.

So if you really want to manage errors (which, as a reminder from above, is a requirement, not a fantasy), you have to prohibit any completely:

• when the type is really not known (which is very uncommon), the right type is unknown,
• when the type is variable, the right solution is a generic.

Note: what are the tools used for doing applications (ie. softwares) until now? Java, C#, C and so on. All have a totally strict typing system.

That is why my feedback is very different: even if the people I teach to are beginning with Angular, they are very often Java or C# developers, which are very aware of the necessity of all this.

Feedback on real projects

I am also a consultant. So I've seen and audited several real Angular projects. Not having started a project in full strict mode is one of the most common issue I see, and one that is very difficult to recover from. Even on medium projects, there are very quickly hundreds and even thousands of non typed code (ie. breaches for errors).

While people who do not understand the issues involved and explained above may find "hard to work" in full strict mode, it is even harder to work in a loose mode project: as time goes by, the code is less and less reliable, meaning more and more bugs, more and more maintenance, etc.

[tayambamwanza]

This is an interesting development, I think removing the no-any is a really big way to defeat the purpose of strict mode, maybe instead of removing it why not add another mode in between or an additional prompt:

"We detected you would like to use strict mode, would you like to include the no-any rule?"
default: yes

everyone goes home happy.

Also it would be nice to know the details of the feedback i.e. source, how large was it etc.

It just helps us get the context and be more accepting of decisions such as these.

[mgechev]

Hi @cyrilletuzi, thank you for the detailed issue. Let me give you some background on the motivation behind our actions.

Ideally, we were hoping to enable the strictest configuration possible for all Angular applications out there. Such precondition would allow us to perform more compile-time optimizations, allow people to catch more issues ahead of time, enable more effective ng update, etc. Our goal was to push this configuration for everyone. Such a massive step, however, would have impacted hundreds of thousands of projects. Imagine a migration of 1m line of code non-strict project to strict mode. Such an effort would probably take months of work, and it could be mostly unnecessary if the project's goals are not focused on performance and strictness, let's say.

That's why we wanted to enable strict mode as an opt-in, be very loud about it through developer outreach explaining its benefits, and later enable a subset of it for every new project. Why did we decide that this would be more efficient than an RFC? The Angular community consists of hundreds of thousands of developers who have different experience levels; most of them are new to web development, type checking, etc. If we enable strict mode, this will impact everyone. Keep in mind that strict mode sets a lot of constraints. Constraints are often useful, but they significantly affect the journey of using and learning Angular. Especially for folks who don't understand static systems, compilers, web tooling, etc. We're building Angular for everyone, which means that we need to consider everyone in any decisions we make.

We usually get 10-40 people to join an RFC discussion. Such a number is significant for a technical discussion, but at the same time, it means that most Angular developers don't spend their time in the GitHub issue tracker; they don't read RFCs and respond to them. That's especially true for beginners. If we share an RFC, we won't hear the beginners' voice in it. We'll only hear from people who have a lot of expertise in the domain - Angular contributors and the Angular team.

Since we've been thinking about side effects, static typing, etc. at the Angular team for quite some time now, we realized we would not be capable of considering all sides. We'll be biased towards what we consider best practices - the strictest configuration possible, making our life easier by enabling more efficient ng update.

What we did instead was:

• Developer outreach where we talk about strictness as much as possible for at least a couple of months. Only I gave 20 talks motivating people to use strict mode
• Talk to a lot of developers on the online events
• Reach out to partners
• Ask prominent educators for feedback on which strict mode settings would make the most sense for beginners
• Write articles and documentation about strict mode and increase their visibility

After that, we took all this information together and tried to consider as many perspectives as possible. We came up with the following plan:

• Shrink the scope of strict mode a little so it can include the strictest configuration possible, without turning developers back form Angular, frustrating them with error messages, and making the learning experience unacceptable
• Consider enabling these settings by default in a future release

At the same time, anyone can enable stricter settings in their project manually. I've turned strict in tsconfig.json and perform webpack tree-shaking wherever possible for all my production apps.

I'd recommend the same to anyone who would benefit from the constraints :)

[cgatian]

Isn't a typical user not going to use the --strict flag on their first project? I've been using Angular for 4 years and didn't even know this was an option. Isn't the flag enough to deter someone that's just getting started from having to understand how typing works?

I work at a company where we have hundreds of C# and C++ devs learning Angular/JavaScript. Our schematics include an even stricter config than the Angular defaults. We aren't worried so much about a barrier to entry, but making sure we are writing good code.

Have you ever seen videos on YouTube where a person opens a glitter bomb? That's how I feel whenever I open a project from a team that has no-any disabled.

[cyrilletuzi]

Hi @mgechev,

Thanks for your answer. But I still don't understand:

Shrink the scope of strict mode a little so it can include the strictest configuration possible, without turning developers back form Angular, frustrating them with error messages, and making the learning experience unacceptable

I understand very well that enabling such rules by default would be a huge step, that would not please some people. But we are not talking about that: again, --strict mode is opt-in and hidden. So it is not enabled by default and not even proposed when doing ng new, so I don't see why it would turn people back from Angular. And someone who wants the easiest learning path just doesn't enable it, and probably doesn't even know about it (it is just very quickly mentioned in the official "Getting started" guide).

The exact purpose for strict mode is to be strict, so for people who want to be strict, and who understand why it is important. It doesn't affect other people (let's say beginners) or existing projects in any way.

That is less important, but for context I would also do some aside comments:

making the learning experience unacceptable

Bold statement. no-any just implies to know about unknown (very simple) and generics (not that difficult, it is the same as function parameters but for types, and are already known by a lot of developers who come from Java, C#, etc.). (Note that I wasn't a Java developer myself, I was a PHP developer before).

The big step is TypeScript strict mode. Adding no-any from that is a little step in comparison.

We're building Angular for everyone, which means that we need to consider everyone in any decisions we make.

While I understand what you are saying in terms of communication/marketing, I am not sure we are helping people by lying to them in technical terms.

Again, Angular is not the new jQuery. Angular is for coding applications. Indeed, it is a lot harder than what we did before in JavaScript. But that is an inevitable fact: people who want to build applications must learn static typing (among many other things), because it is a technical requirement, whether they like it or not.

The term seems to have disappeared from angular.io homepage, but one advantage (ie. why many developers choose Angular instead of React or Vue) is that it is opinionated, ie. is not lying about what is at stake. That's why Angular dropped the pure JavaScript option and forced the use of TypeScript. I know that, in the beginning, forcing TypeScript was badly received by some developers who didn't understand the issues involved. But now years have passed, and in the long term, who was right? Angular. It's because of Angular that TypeScript is now used everywhere.

Real strict mode is just the continuity of that. But here we are not even talking of forcing it: again, it is just an opt-in (and hidden) option.

[cyrilletuzi]

I also want to say again that I do take beginners viewpoint into account, as I am an Angular teacher. So I may be one of the most in contact with beginners. And, very clearly from my experience, real strict mode is not where beginners stumble.

[cyrilletuzi]

At the same time, anyone can enable stricter settings in their project manually.

This is an issue. Even people who are already aware of the importance of strict typings in general are not aware of all the specific TypeScript and linter options. Basically, a Java/C# developer will expect TypeScript to act as Java/C#, ie. being totally strict by default. Often they won't know about TypeScript strict mode, and even less about the no-any lint rule.

So in real-world scenarios, letting people do the configuration manually means that they won't do it at the start of the project, but will discover about that only later in the project, when it is already too late to recover from that.

That is why the Angular --strict option was added. It is its very purpose. Otherwise, why having this option at all?

[leifthomas]

I completely agree with @cyrilletuzi. Strict mode is opt-in only, and should stay that way for all the reasons @mgechev pointed out: it would be unnecessarily difficult for people new to Angular to work in strict mode. But for people who choose to work in strict mode, it should be easy for them to work in the strictest mode possible; that's what they asked for by explicitly choosing strict mode.

Considering people new to Angular is hugely important, probably more than most people realize, but that's why strict is off by default. Justifying the removal of no-any with "It's hard" is no justification at all.

[AlexAegis]

Considering people new to Angular is hugely important, probably more than most people realize, but that's why strict is off by default.

I disagree. Having to work on strict rules from the very beginning eliminates the chance of developing bad habits, like going around TS and placing as any everywhere. Rust doesn't have an easy mode for example, that doesn't stop people from learning it.

Every single corporate project that I worked on did not have strict mode enabled because the angular cli doesn't generate it that way and the developers usually don't care, or know about it. Every single one of them was a mess full with explicit anys. A good chunk of my total dev time on NG projects were spent on reversing the effects that this had.

[cyrilletuzi]

@AlexAegis While I agree with you (and thanks for the support), I just want to clarify that this issue is just asking to let the opt-in --strict mode really strict, nothing more.

If some or all strict options should be enabled or not by default is another debate, but not part of my current request (as I disagree but understand the concerns of the Angular team).

[Aidan-Chey]

In the past I've tried to enable stricter typescript configuration as possible as I figured it would help prevent errors. However going through the options and the typescript docs I found strict and upon trying it found the amount of work to convert my project over to using it was too much at the time. One of the rules that prevented me from doing that was the no – any rule as not a lot of static types had been created beforehand. Removing the need for no - any would prompt me to try again, which I am keen for, as it apparently provides compile time optimisations to reduce bundle sizes.

[cyrilletuzi]

@Aidan-Chey The --strict option we are discussing about only happens, when asked, at project creation (ng new). So existing projects are not concerned.

Indeed, going full strict in an existing project is a lot of work. And this is exactly why it must be, when asked, configured correctly at the very beginning. Then it is too late.

My issue doesn't affect your capacity to just enable strict mode in TypeScript, without the no-any rule.

[leifthomas]

@AlexAegis I completely agree that strict with no-any is definitely the right way to build an app. But it's important that the framework lower barriers to entry. If new developers are deterred from adopting the framework, usage will eventually decline, and the framework will die. It's important for new adopters to see the strength of the framework as early as possible.

I came from AngularJS, and I had a lot to learn from the start:

• Basic ES2015 features like importing and exporting code
• TypeScript features for strict typing
• RxJS and working with Observables

All of that on top of Angular itself was not easy. If I weren't doing it for my job, I'm not sure I would have bothered. It's probably true that you shouldn't be building any real world apps until you're comfortable working in strict mode, but developers need time to get there. And it makes more sense to put the burden on experienced developers to know to use strict mode than to make strict the default and force brand new users to know there's an easier mode for them to learn in.

Another thing that continues to come up is the topic of converting an app to strict mode, which is definitely hard. Today, there's technically no way to do that; you would have to create a new app in strict mode and move the code of an existing app over. That suggests to me that we shouldn't focus too much on taking a non-strict app and making it strict. There may be little value in that. Instead, if you believe strict is the way to go, enable it for the next app you create.

[helmbold]

In most cases the desire to use any points to a design flaw in your own code or in the framework. There are some rare cases where there isn't really another option, but it should be the absolute exception.

The more any is used, the less useful is static typing and in particular TypeScript.

[cyrilletuzi]

@leifthomas I understand that you are answering to another message, but I want to make it very clear again this issue is not asking to enable any strict option by default, but just to let the opt-in --strict mode really strict. Thereby, everyone is happy:

• beginners have a lower learning curve in default loose mode
• people wanting to meet real world professional requirements can use the --strict option

[mgechev]

These are all excellent points, and given the essence of the topic, it's hard to have a single correct answer. Reading through the comments, I see that it might be unclear the goal of strict mode. Our philosophy in the team is to have a single way of doing things. We haven't been able to follow it for all of our efforts, but we do the best we can.

That said, we don't want to have two modes in the CLI indefinitely. Having strict and non-strict mode will add up extra variables to the already complicated structure. Multiple ways of creating a project will be an additional burden for developers, teachers, and ourselves as maintainers.

Our goal with the strict mode is to test how much we can push the strictness boundaries by understanding the adoption and the DX impact of each option. In the future, we will incorporate our discoveries in the default ng-new collection and enable the strictest possible configuration for everyone.

I already mentioned that RFC might not be the best fit for such a feature because of the implicit bias we'll get from advanced developers. Another argument for not proceeding with an RFC is that strict mode is just an experiment. We will consider starting an open discussion when we decide to enable strict options for everyone. In the meantime, we'll gather data through the CLI's telemetry from folks who have opted into it. Having visibility to the adoption will help us make an informed decision.

We'll also consider doing the outreach we already started via blog posts, talks, and documentation. I hope we reach a point when enabling the strictest features in our toolchain will good for everyone.

[cyrilletuzi]

I'm sorry @mgechev but the discussion can't finish like this, because what you say is very surprising.

strict mode is just an experiment.

If it is true, then the communication issues are not just with the community but also inside the Angular team itself. Indeed, nowhere in the schematics code is this feature flagged or commented as experimental, and there is a whole page in the official documentation about strict mode, presenting it as a feature and a good practice, not as an experiment.

That said, we don't want to have two modes in the CLI indefinitely. Having strict and non-strict mode will add up extra variables to the already complicated structure. Multiple ways of creating a project will be an additional burden for developers, teachers, and ourselves as maintainers.

This is an issue only because you started to mix --strict mode with optimization options (like smaller budgets and src/app/package.json). I do agree these things have nothing to do in the --strict mode.

But it is not what was asked by the community. I won't redo the whole history, but the --strict option was asked for years, and the only things we were asking was strict TypeScript compilation, nothing more.

And I really can't see how a pure lint rule like no-any could complicate the maintainers' work.

RFC might not be the best fit

While I understand the bias argument about a RFC, I'm very curious about how and where you get your more legitimate and accurate feedback, given how quickly you shut down a discussion started on the main place where Angular is developed, started by an external contributor who is the author of a tool installed more than 350 000 times, and a discussion already backed up by dozens of people in the only few hours that this issue was allowed to live.

I won't argue more, as I'm very tired of this kind of community management, so for people interested I will reactivate my typescript-strictly-typed project soon.

[mgechev]

It looks like we are all aiming at the same direction - stricter type checking and fewer anys in the code. We are currently holding back a little because we want to ensure we're not leaving beginners behind, so the first step is to continue being loud about strictness and its advantages. :)

@cyrilletuzi typescript-strictly-typed is a great initiative, and its visibility increase will help educate more folks about the benefits of type checking. This will ultimately enable us to turn stricter configuration on by default. The typescript-strictly-typed adoption metrics will be one of the data points we can consider when discussing what strict settings we should enable by default.

[angular-automatic-lock-bot[bot]]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{_This action has been performed automatically by a bot._}