Common TypeScript Error Messages

In the blog post Common TypeScript Error Messages, Sarah Higley provides examples of several common error messages in TypeScript and details how to fix them. The potential issues demonstrated are as follows:

  • Type fails to narrow
  • Flexibly typing objects
  • Third-party libraries and ambient type declarations
  • Conflicting function overloads
  • <any> or as any

One of the more simple errors occurs when trying to assign a number to a unique type:

  • Type ‘number’ is not assignable to type ‘Answer’.

In order to avoid this error, you must simply explicitly type it when its created

const answer: Answer = 42;

or cast it when it’s used.

const result: Answer = answer as Answer;

One of the more complicated errors and potentially more time-consuming to figure out involves a missing declaration file when using third-party libraries, from which not all will necessarily be written in TypeScript. The error looks something like this:

  • Could not find a declaration file for module ‘moduleName’. ‘/path/to/moduleName/lib/api.js’ implicitly has an ‘any’ type.

This can be solved by finding the library you want to use and install it.

She also describes how the overuse of <any> could end up causing errors and that while type casting is powerful because it forces the compiler to interpret the value as the provided type, it’s dangerous because you will no longer see type errors when you missed something.

The reason I chose this particular resource because we’re going to be using TypeScript for our final project so it’ll be useful to know common TypeScript error messages and some of their potential solutions as it’s likely we’re going to be running into these errors in the near future.

As I haven’t done much programming at all in TypeScript yet, I wasn’t able to use this blog to solve any issues that I was running into. But if I were to run into any of these errors in the future, I would be able to save a lot of time compared to if it was my first time encountering the problem. Also, I learned how to cast variables, how to use index signatures and the pros and cons of using them (greater flexibility at the cost of reduced control), how to install third-party JavaScript libraries, how to avoid conflicting function overloads, and to avoid using <any> or “as any” for everything, because even though it could turn out fine there’s a high likelihood that something will end up breaking.



The decorator pattern is used to “decorate” or extend objects with added functionality at run-time. This gives developers the ability to compose objects that are purpose driven for the current demands of their users.

In the blog post How the Decorator Pattern Saved My Day on CodeFX, Nicolai Parlog gives a real life example of how the decorator pattern was useful. He describes a scenario that involves a UI that triggers many different responses depending on the user’s interaction with it. However, different panes may have slightly different responses or needs. He then describes several different ways to implement this:

  • Using one class which activates and deactivates different responses with flags
  • Using inheritance
  • Using the decorator pattern

In the first scenario you would end up with a behemoth of a class that would be hard to write, test, understand, and modify.

The second scenario is a better solution than the first one, however all it did was simulate flexibility, making it seem like you can pick and choose but you couldn’t. When he was trying to replace JEditorPane with FX’ WebView, he realized that WebView automatically triggered some of the responses that were implemented in the second scenario. This caused the whole system of classes to collapse. So he refactored the previous implementation to use the decorator pattern, replacing the original classes with the right combination of decorators. By using decorators instead of inheritance, the classes are easier to understand, it’s easier to test because there are fewer things happening in each unit, and it made the code reader for future changes. Instead of having to figure out where to put new functionality, all you need to do is create a decorator and add it where it’s needed.

The reason I chose this blog is because I have an assignment coming up on this particular design pattern and I didn’t really know what the decorator pattern was and what it was used for in a real world scenario. So I went to search for an example. This blog helped me understand when the pattern should be used and the benefits of using it over other methods like inheritance.  It also reminded me that just because you’re using a pattern doesn’t mean that your code is going to be cleaner or more efficient, but that you have to remember to only use it when necessary, which you can only do if you understand it.


Flaky Tests

Flaky tests are tests that could pass or fail for the same code. This is a problem because the failure of a flaky test doesn’t always indicate a problem with the code, but you can’t just ignore the test because you could be ignoring a bug.

In the the blog post “Where do our flaky tests come from?”, Jeff Listfield, a Senior Software Engineer at Google, talks about the the potential causes of flaky tests and what can be done to avoid creating flaky tests. He demonstrates the correlation between the objective size of the test (binary size, memory usage) and the likelihood for it to be flaky. He also shows a correlation between certain tools and a higher rate of flaky tests, however, the reason for this is because larger tests are more commonly written using those tools. The tools themselves only contribute a small amount to the likelihood of a flaky test being created. When writing tests you should think about what code that you are testing and what a minimal test would look like in order to minimize the likelihood of creating a flaky test.

I chose this topic because effective use of test cases is very important in software development because it allows you to make sure that you’ve addressed and tested all of the product requirements, allows future testers to run your test cases when needed, and also makes it possible to build automated scripts to run as many tests as possible. By writing your test cases out, you also won’t need to constantly repeat the process and remember what values you’re testing every time as they’ll already contain all necessary variables, allowing you to maintain consistency in your tests.

This blog post in particular was interesting because it uses data gathered from real tests used in Google’s continuous integration system to show a cause of flaky tests and how to avoid them. Before reading this blog I didn’t realize how important writing test cases really was, but seeing just how many automated tests that Google used (4.2 million!) which lead to me doing more research on their importance. It also reminded me that the best solution is usually the simplest, in that you should remember to keep your test cases as simple as possible to avoid creating a flaky test and giving you a headache in the future trying to figure out what’s wrong.



The Observer pattern is very commonly used and is one of the Gang of Four design patterns which are meant to solve design problems and create reusable object-oriented software.

The book chapter from the book Game Programming Patterns by Robert Nystrom on the Observer pattern provides an example of its use in specifically game design (an achievement system), however its implementation remains the same as it would in any other type of software. The pattern essentially allows communication between systems without having to couple them together. It does this by creating observers that receive notifications from the subjects that their observing and sharing that information.

In the example provided by the chapter, it shows how a physics system can communicate to an achievement system to unlock an achievement where the player falls off a bridge:


It does this without having to couple the two systems together and eventually creating a huge mess of code.

The author then goes on to describe some concerns and potential problems of using the patterns, such as speed and memory allocation, as well as their solutions. Although even if you implement this or any design pattern correctly and efficiently, it doesn’t mean that it’ll work well depending on whether or not it’s applied on the right problem.

I chose this chapter in particular because it’s likely that we will be using this pattern in the future. Also I think it’s interesting to see how these design patterns can be used in game development, so it may be useful to others who are interested in developing games. I used this pattern in the past for a system where the physics system would notify the observer when a collision happened and it would tell the sound system to play the sound for that collision. I ended up running into a lot of problems due to my poor implementation of the pattern, getting errors because of improper memory allocation. Referencing the examples from this chapter helped me learn how to fix these issues and optimize my code. However, while using the Observer pattern for my audio system worked properly, I ended up doing it differently afterwards using a service locator to provide a global point of access to the audio system as well as an event queue to prevent multiple instances of the same sound from playing at once and blowing out my ears. Although I wouldn’t use the Observer pattern in this situation again, it’ll probably be useful in the future.