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

Add recommended-browser & recommended-node configs #298

Open
buschtoens opened this issue May 24, 2019 · 9 comments
Open

Add recommended-browser & recommended-node configs #298

buschtoens opened this issue May 24, 2019 · 9 comments

Comments

@buschtoens
Copy link
Contributor

I would like to split up the recommended config into recommended-browser and recommended-node. recommended would then just be a merge of both.

Happy to submit a PR, if appreciated. 😊

@buschtoens
Copy link
Contributor Author

We might also want a third config, that has no environment specific rules enabled.

@sindresorhus
Copy link
Owner

Why? In Node.js, the browser rules do nothing, and same the other way around.

@buschtoens
Copy link
Contributor Author

For instance, prefer-node-append and prefer-node-remove were giving me false positives in backend code. In general, it just gives me a more comfortable feeling, knowing that I am only running rules which are applicable to my environment.

I also don't see any downsides to splitting the config, since the external API stays backwards compatible.

Wouldn't have any hard feelings, if you disagree though. ☺️

@sindresorhus
Copy link
Owner

Sounds good. I was just curious about the use-case. PR welcome.

@futpib
Copy link
Contributor

futpib commented May 24, 2019

For instance, prefer-node-append and prefer-node-remove were giving me false positives in backend code.

You can use DOM API in backend code. Maybe we better add an exception to these rules? What kind of code leads to false positives?

@buschtoens
Copy link
Contributor Author

Unfortunately I can't exactly recall the code that caused it. I also think that adding an exception is pretty much impossible, since ESLint is not type-aware. :/

For the few cases where you actually want to use the DOM API in backend code, I personally would rather opt-in to these rules by adding the specific config for these directories.

@sindresorhus
Copy link
Owner

I agree, if you want DOM in Node.js, you just recommended.

@futpib
Copy link
Contributor

futpib commented May 24, 2019

Another option is to make the rules check context.parserOptions.env.browser 🤔 . This way people won't have to specify that they target browsers twice.

@buschtoens
Copy link
Contributor Author

Assuming you would want to use DOM API in Node, would you set the env to node and browser? I never really had the need to mix both contexts, so I am not sure what would be more ergonomic.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants