Extended Diagnostics in Angular
Extended Diagnostics in Angular
Join our very own Doug Parker as he explores Angular’s Extended Diagnostics tooling. What type of extended diagnostic do you think would be great? Let us know in the comments!
Upvote your favorite extended diagnostics proposals and give feedback:
https://github.com/angular/angular/is…
https://github.com/angular/angular/is…
https://github.com/angular/angular/is…
https://github.com/angular/angular/is…
https://github.com/angular/angular/is…
https://github.com/angular/angular/is…
Or suggest your own extended diagnostic:
https://github.com/angular/angular/is…
Join the conversation online:
Angular Twitter → https://twitter.com/angular
Content
0.24 -> have you ever been frustrated debugging
2 -> a complex problem with no good error
4.08 -> message
4.96 -> have you ever wished something would
6.16 -> just tell you exactly what was wrong and
8.4 -> how to fix it then extended diagnostics
10.719 -> might be right for you
22.56 -> howdy my name is doug parker and i'm an
24.48 -> engineer on the angular tooling team i'm
26.64 -> here today to give you an ng update
28.56 -> about how angular's new extended
30.4 -> diagnostics feature will simplify and
32.719 -> streamline your debugging process
35.6 -> extended diagnostics are a new feature
37.36 -> in the angular compiler which flags
39.12 -> coding patterns known to be error prone
42 -> this is done by emitting detailed
43.52 -> warnings during the build it is also
45.6 -> highly configurable and fits into your
47.44 -> team's existing processes
49.52 -> consider this example where i want to
51.199 -> display the user's favorite fruit
53.44 -> i've got a favorite fruit component with
55.039 -> a two-way binding to accept the name of
56.96 -> a fruit and display it
58.96 -> i'm using this in a separate banana
60.559 -> component to display my favorite fruit
62.559 -> bananas
63.76 -> so i'm passing in the string banana to
65.84 -> this two-way binding so it can be
67.2 -> displayed to the user now let's check
69.52 -> out what that looks like
71.2 -> oh no the app is trying to show my
73.36 -> favorite fruit but banana disappeared
75.36 -> for some reason
76.799 -> now well let's check for an error
78.24 -> message in the console
79.84 -> ah there's no error message there either
82.32 -> what could possibly be wrong and how can
84.56 -> i figure this out without any more
85.84 -> information
87.119 -> well as of angular 13.2 you'll now see a
89.84 -> warning on the banana component
92 -> the angular compiler clearly calls out
93.759 -> that something is wrong with my template
95.2 -> binding and gives a detailed error
96.799 -> message explaining exactly what's wrong
99.36 -> in this case my two-way binding was
101.2 -> backwards
102.479 -> we call this the banana in a box error
105.04 -> because the banana referring to the
106.399 -> parentheses should go inside the box
108.64 -> referring to the brackets you see it
110.479 -> looks like banana and it's in a box
112.96 -> it's clever trust me
114.64 -> rearranging the parentheses and the
116.159 -> brackets removes this warning and fixes
118.159 -> my application
119.36 -> now i can tell the whole world about my
120.96 -> love for bananas
122.32 -> banana in a box mistakes like this are
124.56 -> easy to make yet hard to debug and this
127.2 -> was a simple example but imagine the
129.039 -> same mistake in a large component with
131.599 -> five inputs a dynamically computed fruit
134 -> value coming from a surface and passing
136.4 -> through several pipes
137.76 -> it could take hours of trial and error
139.44 -> to narrow down the issue the extended
141.36 -> diagnostic cuts through the noise and
143.28 -> gets right to the problem
144.879 -> now you might wonder why the compiler
146.4 -> flags a banana and box mistake as a
148.64 -> warning and not a hard error
150.8 -> the reason for this is because getting
152.239 -> the two-way binding syntax backwards is
154.72 -> technically valid it's actually an event
157.519 -> binding with a name that just happens to
159.84 -> start and end with brackets this could
161.68 -> happen with native dom elements or
163.519 -> custom web components
165.04 -> extended diagnostics can catch these
166.64 -> kinds of coding patterns which are
168.16 -> technically valid but highly error prone
171.28 -> cases where you think your code is doing
173.12 -> one thing but it's actually doing
174.48 -> something completely different
176.319 -> we've got one more extended diagnostic
177.84 -> for you to check out
179.2 -> here i have a component which shows the
180.879 -> current username and if i don't have a
183.36 -> user then i use the nullish coalescing
185.599 -> operator to default to admin
187.76 -> i mean what could possibly go wrong with
189.36 -> assuming the user's an administrator but
191.36 -> as it turns out i don't even need to
193.12 -> default to admin because username will
195.519 -> never be null or undefined that's not
198.8 -> obvious from looking at this component
200.4 -> on its own but extended diagnostics are
202.56 -> type aware so we can notice that git
205.04 -> username returns a non-nullable string
208.08 -> so the username property is non-nullable
210.799 -> as well i can fix this issue by removing
213.84 -> the knowledge coalescing operation and
215.68 -> reducing the complexity of my code
217.92 -> thanks extended diagnostics
219.92 -> by the way i've been showing you
221.2 -> squiggly underlines added by the angular
222.959 -> language service vs code extension but
225.36 -> you can also see the same errors in your
227.28 -> terminal when running the angular cli
230.08 -> now that you have a better understanding
231.599 -> of extended diagnostics let's talk about
233.439 -> how they can be configured
234.959 -> by default extended diagnostics are
237.04 -> displayed as warnings and don't block
238.959 -> your development workflow
240.799 -> these diagnostics are intended to give a
242.64 -> strong signal when something might be
244.64 -> wrong with your code
246.159 -> different people and teams often have
248.159 -> different preferences about how strict
250.08 -> diagnostics like this should be
252.159 -> so while extended diagnostics are
254.08 -> warnings by default you can configure
256.239 -> them to whatever severity is right for
258.32 -> your project
260.239 -> to do this open your
262.04 -> tsconfig.json file and add an extended
264.96 -> diagnostics object under angular
267.12 -> compiler options
269.04 -> now add a checks object which allows you
271.44 -> to list out specific diagnostics and
273.68 -> what severity you want to use for them
276.96 -> in this case we're treating a banana in
278.8 -> box diagnostic as a hard error which
281.199 -> fails the build
282.8 -> meanwhile any knowledge coalescing
284.56 -> issues are suppressed and ignored
286.479 -> entirely
288 -> now my build fails from the banana and
289.759 -> box error while my knowledge coalescing
292.08 -> issue is hidden
293.84 -> you can also specify a default severity
295.919 -> to use for any diagnostics not
297.6 -> explicitly listed with the default
299.6 -> category option
301.28 -> for example i get two-way bindings wrong
303.44 -> all the time so i appreciate banana in a
305.52 -> box being a hard error but other
308.08 -> diagnostics might not be as critical so
310.4 -> i can suppress all others and reduce the
312.479 -> noise in my terminal
314 -> now custom severity is awesome but often
316.8 -> developers want a middle ground
318.639 -> i know i like a local workflow that's
320.72 -> relaxed flexible and doesn't get in my
323.28 -> way but i also appreciate a code base
325.759 -> with strict and forced standards which
328 -> avoids these kinds of error prone
329.6 -> patterns i don't care about a useless
332 -> knowledge coalescing operator when i'm
333.36 -> aligning css but i do care that my
335.84 -> reviewer doesn't see all my messy
337.199 -> temporary code
338.479 -> so here's a neat trick you can do with
340 -> the angular cli to get forgiving local
342.16 -> builds and strict continuous integration
344.72 -> or ci builds
346.32 -> first make a new file called
348 -> tsconfig.ci.json
350.32 -> in the root of your project then make it
352.639 -> extend our existing
355.08 -> tsconfig.app.json and set your favorite
357.36 -> extended diagnostics to error
359.52 -> this means we now have a ts config
361.52 -> identical to our existing one but with
363.68 -> extended diagnostics overwritten to be
365.68 -> more strict
367.199 -> second open your angular.json file and
369.84 -> find your build target
371.28 -> this likely includes some initial
372.96 -> configurations like production and
374.8 -> development which override certain
376.88 -> options in that builder
378.639 -> add a new configuration called ci which
381.52 -> overrides the ts config option to point
383.84 -> to our new tsconfig.ci.json
387.759 -> you can now add the dash dash
389.44 -> configuration ci option
391.759 -> to the angular cli and it will build
393.759 -> with your new ts config using stricter
396.24 -> options
397.44 -> but since this isn't the default plain
399.68 -> cli commands like ng-serve will continue
402.4 -> to treat these diagnostics as warnings
405.28 -> finally update your ci jobs to include
408.08 -> configuration ci to enforce consistency
410.72 -> for pull requests
412.08 -> while leaving your local development
413.44 -> workflow flexible and keeping you in the
415.36 -> zone
416.479 -> if you're like me and prefer to make
417.84 -> things as strict as you can you might be
420.16 -> tempted to use default category error
422.88 -> this is a great option but keep in mind
424.72 -> that the angular team may introduce new
427.12 -> extended diagnostics in minor release
429.28 -> versions meaning it won't perfectly
431.36 -> adhere to semantic versioning check out
433.44 -> our docs for more information on this
434.96 -> particular edge case
436.479 -> now i know what you're thinking extended
438.4 -> diagnostics kind of sound like linters
440.8 -> formatters or other static analysis
442.88 -> tools and i already have those set up so
445.12 -> how does this help me
446.72 -> well we're also big fans of those tools
448.72 -> and maybe inspired a lot of the design
450.56 -> here
451.52 -> there but there are a few important
452.88 -> differences to call out
454.479 -> linters in particular are an interesting
456.24 -> comparison so let's break that down a
457.84 -> little bit
459.12 -> linters often raise issues which you
460.96 -> probably want to address before
462.4 -> submitting your code but which might not
464.639 -> be urgent or immediately relevant to you
466.96 -> as a developer have you ever been in the
468.879 -> position where your linter is flagging
470.72 -> probably important issues but you kind
472.56 -> of have a production outage to fix
474.96 -> right we've all been there
476.879 -> linting is incredibly helpful but
478.479 -> sometimes are just a higher priority
479.919 -> tasks that need our attention in the
481.199 -> moment
482.4 -> extended diagnostics try to be
484.24 -> immediately relevant and actionable as
486.56 -> you're actively writing code
488.319 -> a banana and box warning could be the
490.16 -> reason some text isn't updating and be
492.319 -> directly related to that outage i'm
493.68 -> debugging i want to know that right away
497.12 -> linters also tend to be focused more on
499.36 -> code style or maintenance issues and
502.08 -> often grow to encompass any kind of
503.759 -> checks you might want to run on your
505.28 -> application source code
506.96 -> this is really powerful and gives a lot
508.879 -> of flexibility in its tooling but it
510.96 -> also means checks vary wildly in their
513.12 -> purpose and usefulness
515.279 -> extended diagnostics take a different
517.2 -> approach and fill a much narrower use
519.2 -> case they specifically address
521.519 -> correctness or performance issues in
523.36 -> your code and that narrower scope allows
525.76 -> us to be more opinionated about them
528.08 -> you can see this in the last comparison
529.519 -> point
530.399 -> linters are frequently executed as
532.399 -> commit or ci checks
534.48 -> after you've written all your code
536.64 -> a lint check telling me my two-way
538.16 -> binding is wrong isn't
540.24 -> useful when i already wasted two hours
542.08 -> debugging to fix that issue it's just
544.48 -> too late to be helpful
546 -> lynchers typically focus on making sure
547.68 -> your code is conformant with the
549.12 -> existing code base
550.88 -> this is often a consequence of the broad
553.279 -> and varied use of lint checks
555.519 -> because extended diagnostics are
556.959 -> narrower in scope the compiler can
559.04 -> comfortably escalate them to you earlier
561.279 -> and trust that they will be relevant to
562.56 -> your current work
564.24 -> now we know that many developers enable
566 -> plugins for their ides to enable lint
568.8 -> warnings in editor and that's a great
570.56 -> option
571.44 -> however this isn't ideal as different
573.76 -> developers often have widely varying ide
576.08 -> setups lots of low urgency checks will
578.56 -> introduce significant noise and an edit
580.959 -> to one file might introduce an issue in
582.959 -> another file that you don't see
585.6 -> extended diagnostics integration with
587.12 -> the build process allows these checks to
589.04 -> be surfaced earlier and with less noise
592.399 -> now the line between a lint check and an
594.959 -> extended diagnostic can get fuzzy at
597.04 -> times
598.16 -> where any given check falls on the
599.68 -> spectrum will vary
601.279 -> some checks will be more useful in a
602.88 -> linter while others will work even
604.48 -> better in an extended diagnostic
606.56 -> we don't see the system as a replacement
608.48 -> for linters or other static analysis
610.399 -> tools
611.36 -> lots of useful checks don't make sense
613.2 -> as an extended diagnostic due to the
614.959 -> different trade-offs and fit better into
616.72 -> other systems extended diagnostics are
618.959 -> simply another tool to leverage in the
620.8 -> fight for maintainable code
622.88 -> now in angular 13.2 we've already
625.2 -> started with these two diagnostics i've
626.8 -> shown you
627.76 -> but we're looking forward to expanding
629.2 -> this system and adding even more awesome
631.36 -> extended diagnostics to make you more
633.04 -> productive
634.399 -> some initial ideas of what these
635.839 -> diagnostics could look like include
637.839 -> requiring triple equals comparisons in
639.6 -> angular templates
640.959 -> we would also like to do more
642.32 -> verification around internationalization
644.56 -> and accessibility
646.399 -> this could include making sure the i 18n
648.88 -> attribute is used everywhere as well as
651.04 -> making sure that aria attributes are
652.88 -> consistent and semantically accurate
655.76 -> we're also hoping to do performance
657.36 -> improvements by requiring router link on
659.36 -> anchor tags and rejecting negated async
662.24 -> pipes
663.519 -> links to all of these and more are in
665.6 -> the description
666.72 -> check them out and don't forget to
667.92 -> upvote anything you really want to see
670.079 -> this helps us prioritize the most
671.68 -> valuable checks and motivates us to make
673.6 -> them happen did you notice anything
675.519 -> missing in that list maybe a cool idea
677.839 -> for an extended diagnostic that you want
679.44 -> to see
680.32 -> we'd love to hear about it slide to our
682.64 -> github issues and make a feature request
684.72 -> we'll be happy to take a look
686.72 -> now this isn't the end of the story for
688.56 -> extended diagnostics we're working on
690.64 -> adding support for vs code quick fix and
693.2 -> custom diagnostic support so you can
695.04 -> write your own checks
696.72 -> we're looking forward to a world where
698.32 -> you can ng-add your favorite library and
701.12 -> immediately get comprehensive error
702.959 -> checking to make sure that you're using
704.8 -> that library in the best possible way
707.44 -> and did you know that one of the best
708.72 -> ways to stay updated about all things
710.399 -> angular is to hit that subscribe button
712.48 -> and click the bell to be notified about
714.56 -> all the awesome new features coming to
716.24 -> an angular near you
717.92 -> you can also follow at angular on
719.68 -> twitter for more excellent web content
722.079 -> now if you'll excuse me this video has
723.68 -> made me quite hungry and i could really
725.12 -> use a snack
727.74 -> [Music]
736.88 -> you
Source: https://www.youtube.com/watch?v=gCKjsd4gaxI