JSX but not React in scope

[HenrikJoreteg]

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]

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]

Why not just disable it for your use case?

Put this at the top of your file:

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

[feross]

@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]

@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]

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]

@HenrikJoreteg want to send a PR?

[HenrikJoreteg]

Sure, will do
On Wed, Dec 2, 2015 at 19:00 Feross Aboukhadijeh [email protected]
wrote:

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

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

[HenrikJoreteg]

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]

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

[feross]

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

[HenrikJoreteg]

right

[dcousens]

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

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

[HenrikJoreteg]

@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]

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

[rstacruz]

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]

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

[HenrikJoreteg]

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 [email protected] 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]

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]

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]

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

[rstacruz]

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]

@rstacruz that would be neat.

[HenrikJoreteg]

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]

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

[feross]

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]

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?

[mike-engel]

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

[feross]

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]

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]

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

[stale]

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

[feross]

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]

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]

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

[ShashwatBag]

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]

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?