Request: replacement for no-restricted-globals

[callumlocke]

I'm using eslint-config-airbnb, which has no-restricted-globals set to disallow certain easily confusable globals, based on the eslint-restricted-globals list.

But sometimes you want to use these globals in types, e.g. to reuse the type of window.history (defined here when creating a customised history for use with react-router:

type History = typeof history;

const createCustomHistory = (): History => {
  // ...create and return a custom history object
}

The ESLint config asks you to change it to type History = typeof window.history. But that doesn't work for Flow – the resulting type is any, as Flow's type for window is is any. Same goes for typeof global.history.

I think it would be useful for eslint-plugin-flowtype to add a new rule, flowtype/no-restricted-globals, which would allow using restricted globals in type annotations.

[gajus]

The ESLint config asks you to change it to type History = typeof window.history

Which rule is that?

This sounds more of a configuration of the rule that is breaking than a case for a new rule.

[callumlocke]

I mean when using the popular shared list at eslint-restricted-globals as config for the rule (as airbnb's config does). The fact is there are some fairly good reasons to restrict names like history so you are forced to access them through a global namespace (as window.history or global.history). But Flow doesn't provide any way to access these things except directly as globals. So if you want to opt into the rule as far as possible, but also want to use Flow, you are forced to break the rule sometimes in type annotations, and use suppressions. So I'm proposing this addition to smooth over the differences. (It would be nicer if Flow would augment their window and global types to include all the globals, but I suspect there's a technical reason why that isn't done already.)

[gajus]

So I'm proposing this addition to smooth over the differences. (It would be nicer if Flow would augment their window and global types to include all the globals, but I suspect there's a technical reason why that isn't done already.)

I don't see a technical reason this cannot be done. This sounds like the right fix. I suggest raising an issue with Flow.