Skip to content
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

JSX but not React in scope #351

Open
HenrikJoreteg opened this issue Dec 2, 2015 · 46 comments
Open

JSX but not React in scope #351

HenrikJoreteg opened this issue Dec 2, 2015 · 46 comments

Comments

@HenrikJoreteg
Copy link

I'm using JSX syntax to generate virtual-dom/h code using babel plugins (this specifically).

Only problem is, now standard complains because React is not in scope.

Not quite sure how this should be addressed, however. Because that check is useful when using React.

@HenrikJoreteg
Copy link
Author

Perhaps it'd just be best to remove that rule? Not having React in scope will blow up pretty quickly. That's doesn't seems like something that would cause subtle bugs, it just blows up :)

@jprichardson
Copy link
Member

Why not just disable it for your use case?

Put this at the top of your file:

/* eslint-disable react-in-jsx-scope */

@feross
Copy link
Member

feross commented Dec 2, 2015

@jprichardson Wouldn't disabling the rule be friendlier for people using React competitors like Riot and Deku? I don't really want to be opinionated and push people to React without a good reason.

@jprichardson
Copy link
Member

@feross yep.

I don't really want to be opinionated and push people to React without a good reason.

Alright, fair enough. While it's nice to have the live feedback in my IDE (linter-js-standard) when I forget to add React with JSX, I definitely understand this perspective and don't have a strong feeling either way.

@dcousens
Copy link
Member

dcousens commented Dec 3, 2015

This error is almost impossible to miss, as the code simply will fail at require time in almost all cases.
I'm OK with it being disabled.

@feross
Copy link
Member

feross commented Dec 3, 2015

@HenrikJoreteg want to send a PR?

@HenrikJoreteg
Copy link
Author

Sure, will do
On Wed, Dec 2, 2015 at 19:00 Feross Aboukhadijeh notifications@github.com
wrote:

@HenrikJoreteg https://github.com/HenrikJoreteg want to send a PR?


Reply to this email directly or view it on GitHub
#351 (comment).

@HenrikJoreteg
Copy link
Author

Didn't know if you need anything else in terms or tests or whatnot. Just tweaked the config in the other module? Just lemme know if i missed something.

@HenrikJoreteg
Copy link
Author

it does raise an interesting question, however. Now what happens to the h that's an unused variable?

@feross
Copy link
Member

feross commented Dec 3, 2015

@HenrikJoreteg So, now you get an unused variable warning?

@HenrikJoreteg
Copy link
Author

right

dcousens added a commit to standard/eslint-config-standard-react that referenced this issue Dec 3, 2015
@dcousens
Copy link
Member

dcousens commented Dec 3, 2015

I merged that change, but, we can roll it back if necesssary.

If h is undefined, then, you should global it out IMHO.

@HenrikJoreteg
Copy link
Author

@dcousens doing /*global h*/ doesn't solve it because h is an unused variable. Have to do: /*eslint no-unused-vars: [2, {"varsIgnorePattern": "h"}]*/

@Flet
Copy link
Member

Flet commented Dec 10, 2015

We currently have a way to define globals via package.json, perhaps we need a way to define unused vars too?

@rstacruz
Copy link
Member

not sure if this is relevant, but setting h as a global in package.json will not throw a no-unused-vars error if it's not used.

@Flet
Copy link
Member

Flet commented Dec 10, 2015

Roger that, @rstacruz! That should be a way to get around the error for sure!

@HenrikJoreteg
Copy link
Author

I agree that'd be a nice way to do it. I could see this kind of thing
happening more and more now that people are doing more things with babel
plugins.

On Wed, Dec 9, 2015 at 9:38 PM Dan Flettre notifications@github.com wrote:

We currently have a way to define globals via package.json, perhaps we
need a way to define unused vars too?


Reply to this email directly or view it on GitHub
#351 (comment).

@rstacruz
Copy link
Member

Running into this myself. When using something else for JSX other than React, a whole slew of errors actually happen. Here's a simple example using deku

/** @jsx element */
import 'element' from 'magic-virtual-element'
import { render, tree } from 'deku'

render(tree(<div class='box'></div>), document.body)
  • 'React' must be in scope when using JSX (react/react-in-jsx-scope)
  • Unknown property 'class' found, use 'className' instead (react/no-unknown-property)
  • "element" is defined but never used (no-unused-vars)

I really wanna use standard on this new project but all of these things make it a pain.

@garth
Copy link

garth commented Jan 10, 2016

Same problem with snabbdom-jsx. We are trying to port cerebral to standard, but hit this blocking issue.

The only way to use standard is to wrap all jsx related imports with

/*eslint-disable no-unused-vars*/

and every jsx file with

/*eslint-disable react/react-in-jsx-scope*/

disabling react-in-jsx-scope is just an inconvenience, but disabling no-unsed-vars is bad.

In order to use jsx with something other than react it is necessary to declare the plugin in your .babelrc

  "plugins": [
    [ "transform-react-jsx", { "pragma": "Component.DOM" } ]
  ]

Maybe standard could check this, then instead of checking for React it could now check for Component and auto fix both of the above rules?

@dcousens
Copy link
Member

@feross perhaps we ditch react in the next major? Is it possible for us to do things like eslint-env react?

@rstacruz
Copy link
Member

As a lateral thought, it'd be nice for standard-engine to pick up your local .eslintrc.

You can set your eslintrc to this:

{
  "extends": ["standard", "standard-react"]
}

...and customize it as you see fit.

@dcousens
Copy link
Member

@rstacruz that would be neat.

@HenrikJoreteg
Copy link
Author

I ended up adding React as a global in package.json which isn't a terrible solution, though a bit hacky.

I almost wonder if standard should just ignore react-related settings beyond tolerating JSX.

@dcousens
Copy link
Member

@HenrikJoreteg it really does feel like it should just be an extension, so I'm not impartial to that either.

@feross
Copy link
Member

feross commented Feb 4, 2016

Yeah, I'd like to eliminate built-in React rules (i.e. eslint-config-standard-react) from standard. We can create a standard-react package for those who want the old behavior, with built-in react support.

@feross
Copy link
Member

feross commented Feb 4, 2016

I'm trying to wrap my head around the unused variable thing. Can someone help me understand?

@rstacruz In your example:

/** @jsx element */
import 'element' from 'magic-virtual-element'
import { render, tree } from 'deku'

render(tree(<div class='box'></div>), document.body)

It does appear that 'element' is an unused variable. I'm guessing that the @jsx pragma thing is actually making use of it, though?

What can standard do to accommodate this better?

@jsonmaur
Copy link

jsonmaur commented Dec 1, 2016

@mike-engel What's the workaround you're using for Preact (if you found one)? As of right now, standardjs seems unusable for a preact app since it catches every instance of h as unused. And I'm not adding /** @jsx h */ to every component file, that seems unreasonable.

@mike-engel
Copy link

@jsonmaur preact didn't end up working back then for what we needed, so we never had to support standard + preact together

@feross
Copy link
Member

feross commented Dec 3, 2016

I am using Preact in a new app I'm building. Right now, I'm just adding /** @jsx h */ to the top of every component file. It's not that bad.

@mattdesl
Copy link

Any chance this could be revisited? It's pretty annoying to have it in every file and adds a deal of visual noise IMHO.

It's easy enough for a power user to automate the comment and understand the importance of it (and why it doesn't appear in React code bases), but for a beginner just starting out with Frontend it's "yet another thing" they have to battle with before they can actually build something.

This affects a lot of frameworks (like hyperapp), not just preact.

Example: You are showing a user how to build a MVC website, and the first line of code they see is a strange comment. Instead of explaining the application to them, the first discussion you'll be having is about JSX, standard, linters, React...

IMHO forcing a comment at the header of each file goes against the main selling points of standard (zero-config, forget about styles & formatting, minimize lint noise to make the errors meaningful, etc).

@feross
Copy link
Member

feross commented May 16, 2018

@mattdesl Re-opening to consider how to improve this in future versions.

@feross feross reopened this May 16, 2018
@feross feross added this to the standard v12 milestone May 16, 2018
@stale
Copy link

stale bot commented Aug 14, 2018

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

@stale stale bot added the stale label Aug 14, 2018
@stale stale bot closed this as completed Aug 21, 2018
@lock lock bot locked as resolved and limited conversation to collaborators Nov 19, 2018
@feross feross reopened this Aug 10, 2019
@stale stale bot removed the stale label Aug 10, 2019
@standard standard unlocked this conversation Aug 10, 2019
@feross feross modified the milestones: standard v12, standard v15 Aug 10, 2019
@feross feross modified the milestones: standard 15, standard 16 Oct 22, 2020
@feross feross modified the milestones: standard 16, standard 17 Oct 29, 2020
@feross
Copy link
Member

feross commented Oct 29, 2020

I would like to address this in a future version of standard. Does anyone have interest in sending a PR to standard-engine to add a jsxPragma option that can get picked up from the package.json configuration key?

@LinusU
Copy link
Member

LinusU commented Oct 29, 2020

React is moving away from requiring that React is in scope, and instead the jsx transpiler adds the appropriate import. Maybe the way forward is to simply disable this rule? 🤔

@feross
Copy link
Member

feross commented Oct 29, 2020

@LinusU Happy to do that! But if we do that will we get another error related to using an undefined variable?

@ShashwatBag
Copy link

I guess JSX needs React to be in scope.

So, if you were to simply import react at the very top, you can get past this problem.

@davidystephenson
Copy link

I am developing a React component as an npm package. I need this rule enabled, otherwise my code cannot be used in other projects. How can I enable react-in-jsx-scope?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: No status
Development

No branches or pull requests

15 participants