Possible Breaking Change in NodeJS definitions on DefinitelyTyped

3
votes

Following the recent change in https://github.com/DefinitelyTyped/DefinitelyTyped/pull/32567, some users may experience compile-time errors when referencing a library built with TypeScript that references the NodeJS definitions on DefinitelyTyped. Library authors may find that the following is now missing from the top of a declaration file output in their compilation:

/// <reference types="node" />
...

This is due to a bug in the emit behavior for declaration files. We recently split the definitions for NodeJS into multiple files included via /// <reference path="" /> tags to improve maintainability and are necessary to support newer TypeScript language features in the NodeJS definitions. Unfortunately, TypeScript's support for automatically emitting /// <reference types="" /> tags doesn't also include path references for "ambient modules". A fix is now available in our master branch and will be available in our next nightly build.

In the meantime, what can users do to work around this change if they are using a version of TypeScript that does not have this fix?

1
typescriptdefinitelytyped

1 Answers

2
votes

End-User Applications

In general, users building end-user applications with TypeScript should not be affected by this change, as it affects declaration file (.d.ts) emit only. If you have already installed the @types/node package to your project's node_modules directory, we will automatically pick up the module declarations for you.

If you have explicitly set the "types" entry in the tsconfig.json for your project and are either using NodeJS or a package that exports types declared in the NodeJS type declarations, you should ensure that "node" is included in the list of types packages to use by default.

Shared Packages

If you are a package author that depends on the NodeJS type declarations in your declaration file output, you are more likely to be affected by this issue. Downstream packages that depend on your package will only be affected if they either:

  • Have not installed the @types/node package as a development dependency.
  • Have a "types" entry in their tsconfig.json that does not include "node".

These consumers can address these issues by ensuring they have @types/node installed and that their "types" (if present) contains "node". They may also be able to work around this issue by specifying "skipLibCheck": true in their compiler options.