Steven Merrill

Why Is TypeScript Picking Up Old Types?

This post was originally posted on the Campfire Learning blog.

At Campfire Learning we have a large TypeScript monorepo containing all the code for our various services as well as our various frontend applications that we use to deliver our curriculum and assessment experiences.

While working on a new backend component, I installed the 1.0 version of the Cheerio XML parser to handle HTML and XML parsing. As I worked in a new package in the repository, I noticed that I was getting errors when trying to initialize a Cheerio 1.0 parser through its load() method:

const htmlFragmentParser = cheerio(myText, null, false);

I was getting the following build error and it took me a bit to figure out what was going on.

$ tsc
Error: src/parser.ts(6,41): error TS2554: Expected 1-2 arguments, but got 3.

On one level, this made sense; Cheerio 1.0 puts its parsers into document mode by default and added the third isDocument? Boolean parameter to specify if it should operate in document or fragment mode. Still, we are using Yarn workspaces, and the particular package I was working in specified Cheerio 1.0 as a dependency. So why was the old method signature being applied?

As it turns out, the problem is with TypeScript (the error is coming from the tsc command.) As TypeScript's documentation for the types key notes:

By default all visible "@types" packages are included in your compilation. Packages in node_modules/@types of any enclosing folder are considered visible. For example, that means packages within ./node_modules/@types/, ../node_modules/@types/, ../../node_modules/@types/, and so on.

So even though Yarn taked care of setting up a node_modules folder per package in our monorepo, TypeScript will blythely traverse up the directory hierarchy looking for any @types packages. Our repository has the @types/cheerio package from the old version of Cheerio.

Additionally, Cheerio started shipping its own types in 1.0, so no more @types package is needed to get full type information. Armed with this knowledge I was able to set the types property in our newer monorepo packages that use Cheerio 1.0 so that the old @types/cheerio package was not detected.