Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Node module dependencies that use a triple-slash directive to reference libs poison the global scope

See original GitHub issue

TypeScript Version: 2.x, 3.x

Search Terms: lib.dom.d.ts pollutes global scope, name is defined as never, event is defined as Event | undefined

See: at the commit hash linked.

Expected behavior:

Given a tsconfig.json with lib: [], I would expect the following code to fail to build due to $variable not defined errors:

import is from '@sindresorhus/is';

function main() {

Actual behavior:

See: for a particularly egregious example of this. It builds without any type errors. When running npm run start, it will throw a runtime error on the first console.log. If you remove that line, the next one fails, and so on, for the next 700+ lines.

General purpose libraries often need to be written to handle multiple versions of ES (ES5, ES6, ES7…) and multiple host environments (e.g.: DOM, ScriptHost, WebWorker). But right now they are faced with a choice:

A: Use a triple slash directive to import types that they use, and poison the user’s global scope, causing nearly one thousand variable names to be silently accepted as defined without any type checker errors.

B: Remove the triple slash directives and require that users use the --skipLibCheck option or equivalent in their config file or include the required libs in their compiler options. Otherwise the library will fail to type check.

This is a choice that library authors would quite reasonably not want to make.

Potential solutions:

  1. Triple slash directives should import types only in dependencies.

    This seems tricky to implement, I think.

  2. There should be a types-only version of the major lib files, so that general-purpose utility packages can reference those instead.

    This seems less tricky: extract all the types from the dom lib a new dom-types lib, and use a directive to reference the types. Then, library authors can triple-slash reference dom-types and get only the types. Has the advantage of not causing any compatibility issues, and library authors can opt in to the types-only package.

  3. ???

Issue Analytics

  • State:open
  • Created 4 years ago
  • Reactions:15
  • Comments:5 (1 by maintainers)

github_iconTop GitHub Comments

AaronFrielcommented, Aug 28, 2019

@fatcerberus Yes, that’s right, I started to comment and realized I wasn’t quite clear with what my option B meant. I edited it to this:

B: Remove the triple slash directives and require that users use the --skipLibCheck option or equivalent in their config file or include the required libs in their compiler options. Otherwise the library will fail to type check.

It’s removing the triple slash directive that was missing from my description. The dependency will build fine (tsc emits no errors as long as the libs are added to the compiler options), but unless a downstream consumer of the package uses --skipLibCheck (or includes the missing libs in their compiler options), their build will fail.

Georiftcommented, Nov 6, 2020

@rbuckton hadn’t you considered option (2), creating standalone versions of the built-in lib files?

Do you have and updates on this? I don’t know how prevalent this problem is in other packages, but we’re butting up against it in @types/superagent now. (DefinitelyTyped/DefinitelyTyped#41425) If you have any guidance that’d be awesome 🙂

Read more comments on GitHub >

github_iconTop Results From Across the Web

package.json - npm Docs
Description. This document is all you need to know about what's required in your package.json file. It must be actual JSON, not just...
Read more >
How to make an NPM module with globally accessible types
I had to solve this for my logging library, winston-jsonl-logger . It augments the global scope with a global variable called logger ....
Read more >
Documentation - Publishing - TypeScript
Dependencies. All dependencies are managed by npm. Make sure all the declaration packages you depend on are marked appropriately in the "dependencies" section ......
Read more >
Requiring modules in Node.js: Everything you need to know
Node uses two core modules for managing module dependencies: The require module, which appears to be available on the global scope — no...
Read more >
Modules: Packages | Node.js v19.3.0 Documentation
json file, or a folder named node_modules . This page provides guidance for package authors writing package.json files along with a reference for...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Post

No results found

github_iconTop Related Hashnode Post

No results found