Many globals have been added, particularly GM_addElement. Check the list.

I don't think any of the globals defined for wsh should be writable. Although I followed that convention in #156, since all currently defined globals are writable, I can't think of a valid reason to overwrite these globals beyond any other built-in global. What would you think about making them all non-writable?

Thanks for considering,
Kevin

It's not documented, but Jest uses global as the window object. I figure we should add that guy right here. Not sure if there was a reason this was excluded though.

While investigating why eslint wouldn't pick up the BigInt globals, I noticed eslint does not use builtin like I previously assumed. I'd like to propose to copy any globals missing in either es5, es2015, es2017 but present in builtin to one of those respective environments.

Afterwards, I'd copy back any potential globals from the es* categories to builtin so that it ends up containing all globals from those categories. Alternatively, builtincould be generated dynamically in index.js, I think actually, that'd be my preference to avoid future inconsistency.

I’m currently working on a project that uses a variety of WebKit-specific globals when they are available, e.g. WebKitPoint. Would it be reasonable to include those here?

In general, is there a policy on the inclusion of vendor-prefixed globals (things intended to be or on their way to standardization) or vendor-specific globals (things only available on a given platform)?

I'd do it myself if I was added on npm.

I use this to access the window prototype (same as window.__proto__).

I ran into a problem where ESLint was not detecting the use of an undeclared variable, Promise.

How do we determine what qualifies as a global? In this particular case, Promise is not a global in IE (or ES5). Should it be excluded?

Should we have separate versions of globals.json for different versions of EcmaScript?

Hi, I was using ESLint and it recommended me using path.join instead of concatenating strings, i changed it, but the linter told me path was not defined. A quick search showed me that path belongs to node, I realized they were using this lib, so I searched here for the key and could not find path inside the globals.json

If you want, just tell me and I can make a pull request adding "path": false inside globals.json. But first confirm me if path actually belongs to node (I dunno if i missed something).

See ya!

These are in the nonstandard environment, which currently isn't imported by eslint. As they are not going away anytime soon and are defined in node and the browser, I think they belong in the builtin category.

Another approach would be that eslint imports this nonstandard environment where needed, but I'm more in favor of removing the nonstandard category all together. Opinions?

I'd like to see the new globals from jasmine 3.4 added to the globals list, so that specifying env: jasmine in eslint includes globals like spyOnAllFunctions without having to add it manually to the .eslintrc.

I see the discussion in #82, and I'm not sure what the current status is -- is globals accepting PRs for adding globals to existing definitions, or is it already moving to separate plugins?

There exists a plugin today, eslint-plugin-jasmine, that is only a bundle of rules today. I'd be willing to make pull requests there to propose exporting a custom env, but if it exports the env "jasmine", will that be useable in .eslintrc? (I assume, perhaps, it would be env: "jasmine/jasmine" instead of just "jasmine").

Looking for input on where I should be making these changes...

DOMRectList was introduced to Chrome & FF shortly after DOMRect & DOMRectReadOnly

It is the return type of Range#getClientRects, e.g. document.createRange().getClientRects()

There are several other IndexedDB-related globals besides just indexedDB, most notably IDBKeyRange which is used very commonly. Should all of these IndexedDB globals be listed here? Just the ones that are commonly used? None of them?

Would be nice to have parity between them.

Now included in ESLint. Still need to convince JSHint though.

https://developer.mozilla.org/en-US/docs/Web/API/WorkerGlobalScope

npm@7 rejects installing packages that require a newer version of type-fest because this package depends on a specific old version of it.

The "mongo" env is currently for mongo shell (https://docs.mongodb.org/manual/reference/method/), but Mongo also has another context for JavaScript execution - Mongo server-side scripts (https://docs.mongodb.org/manual/core/server-side-javascript/), which has an almost completely different set of predefined globals (https://docs.mongodb.org/manual/reference/operator/query/where/#behavior). There really should be two separate environments for Mongo. I think the names "mongo-shell" and "mongo-server-side" would be most intuitive. I'd suggest making the current "mongo" env a deprecated alias for "mongo-shell".

If the powers that be agree this is a good idea, I can create a PR. Please let me know.

I noticed that some of the properties in the JSON file are true while most are false. Is there a reason for this, and if so can it be documented?

Greasemonkey 2.0 added these three functions to the userscript scope in response to https://blog.mozilla.org/addons/2014/04/10/changes-to-unsafewindow-for-the-add-on-sdk/

Greasespot blog on the topic: https://www.greasespot.net/2014/06/greasemonkey-20-release.html

Tampermonkey added the same functions for cross-compatibility around the same time? I can't find the changelog and, due to the different structure internally, these functions aren't required for userscripts in Tampermonkey.

As of Greasemonkey 4.7 all three functions are still in the global namespace and not using them generates Error: Permission denied to access object errors in Firefox 64.

Recommendation from Greasemonkey to continue using cloneInto() and exportFunction() post-GM4: https://www.greasespot.net/2017/09/greasemonkey-4-for-script-authors.html

Documentation from Mozilla, updated in September 2018: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Sharing_objects_with_page_scripts#Sharing_content_script_objects_with_page_scripts

I'll put together a PR.

I just noticed, while setting up a new project, that the serviceworker list doesn't appear to include URL and fetch, while worker does. Since 'serviceworker' inherits from worker, according to MDN, this seems incorrect to me.

It's also possible I'm misunderstanding the issue. It also seems at a short glance that #82 will introduce inheritance so this would be magically solved in the future.

Since Tampermonkey / Violentmonkey utilization vastly exceeds the original Greasemonkey, Greasemonkey doesn't seem to be very actively developed anymore, and most people consider them nearly the same, would be great to add the few missing globals so separate environments didn't need to be created for the minor differences:

• GM_addValueChangeListener (TM/VM)
• GM_download (TM/VM)
• GM_getTab (TM only?)
• GM_getTabs (TM only?)
• GM_notification (TM/VM)
• GM_removeValueChangeListener (TM/VM)
• GM_saveTab (TM only?)
• GM_unregisterMenuCommand (TM/VM)

Source:
TM: https://www.tampermonkey.net/documentation.php#api
VM: https://violentmonkey.github.io/api/gm/

This split is a bit arbitrary right now, as the typed arrays are in builtin while Symbol is in ES6.

In ESLint, we've just been putting all ES6 stuff into builtin. I'm not sure if there's a good reason to have them separate.

Like the title says, I've noticed that the type-fest package is included in the dist even though index.d.ts (which is in this repository and uses the said package) is not included in the dist. @sindresorhus Mistake?

window.event Microsoft-only so should be removed
https://developer.mozilla.org/en-US/docs/Web/API/Window/event

The XDomainRequest global is not documented in the JScript Reference or WSH Reference and I can confirm that it is not present on Windows 7 or Windows 10.

Thanks,
Kevin

Note: Issue removed from #154 as requested in #154 (comment)

        "ArrayBuffer": false,
        "Float32Array": false,
        "Float64Array": false,
        "Int16Array": false,
        "Int32Array": false,
        "Int8Array": false,
        "Uint16Array": false,
        "Uint32Array": false,
        "Uint8Array": false,
        "Uint8ClampedArray": false,

These are all available in node, not just browsers.

#143 Broke eslint. If I change my variable to Location and not location then it passes eslint.

Maybe add a new environment "node10"?

I was wondering if the Ember.Test methods could be added to the globals. I'm currently manually adding them to my globals in tests/.eslintrc for an ember-cli project. But it would be nice to just use an env setting. Would you accept a pull request for them?

Related to: eslint/eslint#2870

The Web Animations API spec is being implemented in Firefox (parts have already shipped in FF46/47, and there's more to come) and Chrome (unsure about the version), and it's on Edge's roadmap.

This spec brings a number of new constructors available globally in a browser environment:

• KeyframeEffect
• KeyframeEffectReadOnly
• AnimationTimeline
• Animation
• AnimationEffectTiming
• AnimationEffectTimingReadOnly
• AnimationEffectReadOnly
• SharedKeyframeList

Maybe more that I have missed.
These should be added to the list of globals in this project. I'd be interested to contribute this if you let me know how to get started (seems like a simple enough change in the json file, but maybe I'm missing something).

It's my understanding that this is, in turn, used by eslint to validate script in browser environments.

I think that yours get-browser-globals.js don't works well test. Here what I got:

• run script from get-browser-globals.js
• copy my code to the json file
• run npm run test
• get an error that upperCase letter must be before LowerCased

So I also fix the get-browser-globals.js script to avoid that.

Hi,
would it possible to include in this package a list of global constructors?

Context
I'm working on a Babel PR (babel/babel#7020) to add support for extending builtins (e.g. class exends Array {}).
Unfornuately native functions require special handling when extended in the "old way", so I had to hard-code a list of them (https://github.com/babel/babel/pull/7020/files#diff-3c1cae954a3a2ef02f5c3abc41a33978). Would it be possible to store that data in this package?

Possible implementations

1. Use a new flag.

{
  "Array": false
}

would become

{
  "Array": { "writeable": false, "constructor": true }
}

2. Use a new list
   e.g.

require("globals").builtinConstructos;

I personally prefer the first option, but it would be a breaking change.

In the beginning, I think the purpose of this package was to have a single location where the commonly-used globals for JavaScript lived, with the idea that other tools could make use of it.

What we've been seeing, though, is that most requests for new environments come from ESLint users who want an environment for their favorite library. This ends up breaking the feedback cycle where people file issues here instead of with ESLint, meaning the ESLint team doesn't even see them.

Given that ESLint now supports plugins with custom environments, I think we should re-think the goals of this project. Maintaining a list of every library's global objects is something I'm really not interested in doing, and realistically, in the future we'll only care about the ES environment globals because everyone will be using modules, so library-specific globals will be going away.

I'm thinking that maybe this package should be repurposed to just be ES language versions, browser globals, and Node.js globals, and leave the rest to others.

Thoughts?

window.external does not seem exist for these browsers, causing consuming packages (eslint) to not properly catch bad code.

any chance we could add it? so I won't have to disable the highly important no-undef eslint rule. or please advise if I'm doing something wrong. thanks!

Hi,

What's your feeling about adding all the standard DOM events in the browser environment ?

Currently, there is only Event, CustomEvent and MouseEvent in it.

The shared memory proposal has reached stage 4, so ES2017 will have two new builtin globals: Atomics and SharedArrayBuffer.

I saw in the readme that this package is no longer accepting new environments. Does that also apply to environments for new standardized JS globals?

If the new environment will be added to this package, what should it be called? es8 would be consistent with the existing es6 environment, but es2017 is the canonical name for the spec.

Continuation from eslint/eslint#9621 (comment) :

Tell us about your environment

• ESLint Version: 4.11.0
• Node Version: 9.1.0 x64
• npm Version: 5.5.1

What parser (default, Babel-ESLint, etc.) are you using? default

Please show your full configuration:

module.exports = {
    "env": {
        "browser": true,
		"greasemonkey": true,
    },
	"extends": "eslint:recommended",
    "parserOptions": {      // see https://eslint.org/docs/user-guide/configuring
        "ecmaVersion": 8,
        "sourceType": "script",
        "ecmaFeatures": {
            "impliedStrict": true,
        }
    },
    "rules": {
        "semi": ["warn","always"],
    }
};

What did you do? Please include the actual source code causing the issue, as well as the command that you used to run ESLint.

// ==UserScript==
// @name     GM set/get demo
// @grant    GM.getValue
// @grant    GM.setValue
// ==/UserScript==

(async function() {
	let i = await GM.getValue('i', 0);
	GM.setValue('i', i + 1);
})();

eslint 1.js

What did you expect to happen?

No errors should be found.

What actually happened? Please include the actual, raw output from ESLint.

It found the following 2 errors:

C:\Users\Kostas\Desktop\1.js
  8:16  error  'GM' is not defined  no-undef
  9:2   error  'GM' is not defined  no-undef

✖ 2 problems (2 errors, 0 warnings)

That's because, since Greasemonkey 4.0 :

There is only one object provided to user scripts now, named GM.
It has several properties. One of them is info – the equivalent of the old GM_info.
There are also several methods of this object:

• getResourceUrl,
• deleteValue,
• getValue,
• listValues,
• setValue,
• xmlHttpRequest.

To use these methods you still need @grant, and use the new name, e.g.:

 // @grant GM.setValue

The new form has a dot, where the old form has an underscore.
You may specify both @grants, if you'd like to be compatible with Greasemonkey 4 and other user script engines at the same time.
As of today, there is no support for:

• GM_log (use console.log),
• GM_addStyle,
• GM_registerMenuCommand, nor
• GM_getResourceText.

The complete list of the GM obect's properties is the following: (Greasemonkey_Manual:API)

• GM.info
• GM.deleteValue
• GM.getValue
• GM.listValues
• GM.setValue
• GM.getResourceUrl
• GM.openInTab
• GM.setClipboard
• GM.xmlHttpRequest, and
• unsafeWindow

In other words, the 'Greasemonkey' environment should be updated to include the GM object and its properties. (all the old GM_* grants should also be maintained, even the 4 currently not supported ones, for use by other script engines) .

I also quote the reply by @platinumazure :

Our environment globals come from the globals repository. I think it would probably make more sense to file an issue there.

Looking at their main global data file, I see that the old properties are the only ones present

Can we add service worker globals?

https://developer.mozilla.org/en-US/docs/Web/API/ServiceWorkerGlobalScope

Not sure how this was missed, but the browser environment is missing console as a global. We should add that.

Right now the globals for node include identifiers that aren't real globals but are artifacts of the fact that historically most code has been running inside of CommonJS wrapper functions.

A "true" globals environment for node may look like this:

 	"node": {
-		"__dirname": false,
-		"__filename": false,
 		"Buffer": false,
 		"clearImmediate": false,
 		"clearInterval": false,
 		"clearTimeout": false,
 		"console": false,
-		"exports": true,
 		"global": false,
 		"Intl": false,
-		"module": false,
 		"process": false,
 		"queueMicrotask": false,
-		"require": false,
 		"setImmediate": false,
 		"setInterval": false,
 		"setTimeout": false,
 		"TextDecoder": false,
 		"TextEncoder": false,
 		"URL": false,
 		"URLSearchParams": false
 	},

Since the name "node" is already taken, maybe it could be called "nodeBase"? Or "nodeButOnlyTheActualGlobals". I honestly don't have a good name yet.

Happy to create a PR if the overall direction makes sense.

According to the QUnit 2.x Upgrade Guide, all of the globals except for QUnit are going to be deprecated in QUnit 2.0 and removed in QUnit 2.1. Is it worth creating a new "qunit2" section to reflect this?

Note that I have no idea when QUnit 2.0 is actually coming out, so if we agree that this is worth doing later but not now, that is fine too.

jshint/jshint#1827

Even though it isn't technically a global, would you consider adding toString to this list?

For context, I'm trying to use this module to avoid problems while manipulating identifiers in an AST. toString treated like a global is a case where this is failing.

These two variables are deprecated in node v6.0.0: nodejs/node#1838 which are never documented and should be safe to remove. By removing root from node's env, it should help those developers that accidentally access global root variable.

I also filed an issue in ESLint: eslint/eslint#9144

Hello. I want to use your package for my one. Not sure if that is not exist already. But anyway.
The problem that when I start to test my package I found 17 global vars in the chrome incognito mode.
Here is the list:

0: "onformdata"
1: "onwebkitanimationend"
2: "onwebkitanimationiteration"
3: "onwebkitanimationstart"
4: "onwebkittransitionend"
5: "onselectstart"
6: "onselectionchange"
7: "captureEvents"
8: "releaseEvents"
9: "webkitRequestAnimationFrame"
10: "webkitCancelAnimationFrame"
11: "webkitStorageInfo"
12: "chrome"
13: "onpointerrawupdate"
14: "webkitRequestFileSystem"
15: "webkitResolveLocalFileSystemURL"
16: "trustedTypes"

I forked your repo and want to add them if they all are the default now for Chrome too.

This was a stackoverflow question - https://stackoverflow.com/q/53906051/1828637

He has a const payload = [{ id: 0 },{ id: 1 }] and wants to do the following:

expect(payload).to.nested.include({
  '[0].id': 0,
  '[1].id': 1
});

But it does not work. He has to wrap it to get this to work:

const wrappedPayload = { a: payload };
expect(wrappedPayload).to.nested.include({
  'a[0].id': 0,
  'a[1].id': 1
});

I think this is a bug.

First line of the README.md (https://www.npmjs.com/package/jest-cli)

Adaptable: Jest uses Jasmine assertions by default and Jest is modular, extendible and configurable.

Jest entry should contain only its own global vars (jest, gen, few others,...)

Users would have to declare both jest and jasmine env if they used Jest with Jasmine.
It would be more respectful of the Jest's architecture and easier to maintain here (Jest and Jasmine entries are actually quite a mess 😥 ).

EventSource should be an available global for browser environments: https://html.spec.whatwg.org/multipage/comms.html#the-eventsource-interface

Happy to make a PR.