Skip to content

eslint ignores variables named status #1834

Description

@sidoshi

Can you reproduce the problem with latest npm?

yes. npm version: 4.1.1

Description

Linter ignores status variable name when checking for unused vars.
Not sure if this is a bug or expected behaviour.

Expected behavior

It should probably warn when I have not declared a variable named status and have this line of code:
console.log(status)

Actual behavior

Even though I have not declared any variable named status,
using it does not show any warning or errors.
it shows no-undef error on all other variables names like statuss as expected

Environment

Run these commands in the project folder and fill in their results:

  1. npm ls react-scripts (if you haven’t ejected): 0.9.0
  2. node -v: v7.7.1
  3. npm -v: 4.4.1

Then, specify:

  1. Operating system: Linux, Deepin
  2. Browser and version: any

Reproducible Demo

create a new app with:
create-react-app test-app
In index.js type: console.log(status)
It won't show any error that status is not defined but changing the variable name to statuss would show error as expected

Activity

  1. n3tr commented on Mar 15, 2017

    @n3tr
    Contributor

    As I understand it is expected behavior since status is a window property (https://developer.mozilla.org/en-US/docs/Web/API/Window/status) and we configure eslint env. browser on eslint-config-react-app/index.js#L29

  2. gaearon commented on Mar 15, 2017

    @gaearon
    Contributor

    It's still confusing and IMO we should forbid implicit window properties without window. qualifier.

  3. sidoshi commented on Mar 15, 2017

    @sidoshi
    ContributorAuthor

    I think eslint doesn't support that.
    See eslint/eslint#3959 .
    It seems like we would have to remove browser env and add a list of some variables to globals like localStorage.

  4. gaearon commented on Mar 15, 2017

    @gaearon
    Contributor

    I don't mind having our own list of globals.

  5. sidoshi commented on Mar 15, 2017

    @sidoshi
    ContributorAuthor

    I can work on this.

  6. gaearon commented on Mar 15, 2017

    @gaearon
    Contributor

    Sounds good!

  7. sidoshi commented on Mar 17, 2017

    @sidoshi
    ContributorAuthor

    see #1840

  8. added this to the milestone on Mar 27, 2017
  9. reopened this on May 8, 2017
  10. gaearon commented on May 8, 2017

    @gaearon
    Contributor

    I think I was wrong about this. People are genuinely confused when “valid” globals don’t work—especially if they’re built into the browser.

    I propose another strategy. Let’s go through the list of globals and pick a list of names that can genuinely be confused with local variables (e.g. status is a great candidate). It’s gonna be subjective but I’m okay with that.

  11. gaearon commented on May 14, 2017

    @gaearon
    Contributor

    Fixed by #2130 with an explicit blacklist.

  12. gaearon commented on May 16, 2017

    @gaearon
    Contributor

    Please help beta test the new version that includes this change!
    #2172

  13. locked and limited conversation to collaborators on Jan 21, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions