globals

What is globals?

The 'globals' npm package provides a collection of global identifiers for various JavaScript environments. It's useful for linting purposes to define a set of global variables that are considered to be legal and expected in a given environment, such as browser, Node.js, or other environments like testing frameworks.

What are globals's main functionalities?

Environment-specific globals

This feature allows you to specify a set of globals for browser environments. When set to true, it includes all the global variables that are expected to be available in a browser context, such as 'window', 'document', etc.

{"browser": true}

Node.js globals

This feature provides a list of global variables specific to Node.js, such as 'global', 'process', 'Buffer', etc. It's useful when you're working in a Node.js environment and want to ensure your linting tools are aware of these globals.

{"node": true}

CommonJS globals

This feature includes globals related to the CommonJS module system, such as 'require', 'exports', and 'module'. It's helpful when working with CommonJS modules to avoid linting errors related to these global identifiers.

{"commonjs": true}

ES6 globals

This feature includes new global variables introduced in ES6/ES2015, like 'Promise', 'Set', 'Map', etc. It's useful for projects that are using ES6 features and want to ensure that these new globals are recognized by linting tools.

{"es6": true}

Testing framework globals

This feature provides globals for the Mocha testing framework, such as 'describe', 'it', 'beforeEach', etc. It's useful for projects that use Mocha for testing to prevent linting errors related to Mocha's global variables.

{"mocha": true}

Other packages similar to globals

eslint

ESLint is a popular linting tool for JavaScript and JSX. While not a direct alternative to 'globals', it uses the concept of environments, which can be configured to include global variables for specific environments, similar to what 'globals' provides. ESLint is more comprehensive as it includes not only global variable definitions but also a wide range of linting rules for code quality and style.

jshint

JSHint is another linting tool that can be configured to recognize global variables in different environments. Like 'globals', it allows you to specify which global variables are allowed in your code to prevent linting errors. JSHint is less customizable than ESLint but serves a similar purpose in managing global variables for linting.

tern

Tern is a stand-alone code-analysis engine for JavaScript that, among other features, can be used to recognize global variables in different environments. While it is not a linting tool per se, it provides functionality that overlaps with 'globals' by understanding the scope and context of code, including global variables.

README

globals

Global identifiers from different JavaScript environments

It's just a JSON file, so use it in any environment.

This package is used by ESLint.

This package no longer accepts new environments. If you need it for ESLint, just create a plugin.

Install

npm install globals

Usage

const globals = require('globals');

console.log(globals.browser);
/*
{
	addEventListener: false,
	applicationCache: false,
	ArrayBuffer: false,
	atob: false,
	…
}
*/

Each global is given a value of true or false. A value of true indicates that the variable may be overwritten. A value of false indicates that the variable should be considered read-only. This information is used by static analysis tools to flag incorrect behavior. We assume all variables should be false unless we hear otherwise.

For Node.js this package provides two sets of globals:

• globals.nodeBuiltin: Globals available to all code running in Node.js. These will usually be available as properties on the global object and include process, Buffer, but not CommonJS arguments like require. See: https://nodejs.org/api/globals.html
• globals.node: A combination of the globals from nodeBuiltin plus all CommonJS arguments ("CommonJS module scope"). See: https://nodejs.org/api/modules.html#modules_the_module_scope

When analyzing code that is known to run outside of a CommonJS wrapper, for example, JavaScript modules, nodeBuiltin can find accidental CommonJS references.