Skip to content

[New] : Avoid unsafe global window use #2692

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

jzabala
Copy link
Contributor

@jzabala jzabala commented Jun 30, 2020

This rule will prevent the unsafe use on window resulting from rendering React apps in environments where the global is not available.

I'll be grateful for getting all your comments and suggestions before summiting the final version.

Tested Conditions

  • used in a guard
  • used in componentDidMount, componentDidUpdate and componentWillUnmount
  • used in useEffect, useLayoutEffect and useCallback
  • used in an event handler

Considerations

The issue talks about disabling the use of various globals variables aside from window. I think an easier solution would be to use the rule no-restricted-globals to force the use of window in the variables that we want.

Another solution would be to have the option of setting what globals will be disabled directly in this plugin with window as default. And to change the name of the rule to something like: no-unsafe-globals-use.

Let me know your opinion about this or if you have other ideas

Closes #2057

@ljharb ljharb marked this pull request as draft July 5, 2020 21:54
Copy link
Member

@ljharb ljharb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks like a good start :-)

@jzabala jzabala force-pushed the feat/rule-no-unsafe-window-use branch 2 times, most recently from a7bfeca to 6e436a9 Compare July 6, 2020 17:13
@jzabala jzabala changed the title WIP [New] : Avoid unsafe global window use [New] : Avoid unsafe global window use Jul 6, 2020
@jzabala jzabala marked this pull request as ready for review July 6, 2020 17:23
@jzabala
Copy link
Contributor Author

jzabala commented Jul 6, 2020

This looks like a good start :-)

Thanks for your initial review @ljharb.

I think it is ready now 🙂

@jzabala jzabala force-pushed the feat/rule-no-unsafe-window-use branch from 6e436a9 to 988eaf1 Compare July 6, 2020 18:30
@osdiab
Copy link

osdiab commented Oct 24, 2020

i'm interested in this rule or something like it getting published - anything that needs to be done to help it along?

@osdiab
Copy link

osdiab commented Oct 24, 2020

FYI currently this errors incorrectly:

typeof window === "undefined" ? undefined : window.location.href

Alternatively,

if (typeof window === "undefined") {
  return;
}
console.log(window.location.href);

Also shadowing window still causes errors, like so:

function getWindow() {
  return typeof window !== "undefined" ? window : undefined;
}

// another file
const window = getWindow(); // this line errors but pretty sure it's actually fine
console.log(window?.location.href); // this errors too

though just giving it a different name works fine.

@osdiab
Copy link

osdiab commented Oct 24, 2020

also would probably make sense to check for document, but yeah maybe that makes more sense for no-restricted-globals

Copy link
Member

@ljharb ljharb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems like this also needs handling for hooks in SFCs, to ensure window and whatnot is only used in effects?

I'm not stoked on the use of a class and this, or all the loops, in the implementation, but that's something we can worry about later.

@ljharb ljharb force-pushed the master branch 2 times, most recently from 380e32c to 51d342b Compare July 4, 2024 15:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

Successfully merging this pull request may close these issues.

Rule proposal: ssr-friendly
3 participants