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

Can we ignore `require.resolve` in `try/catch` block for rule `node/no-extraneous-require`? #185

Closed
JounQin opened this issue Sep 7, 2019 · 6 comments
Labels

Comments

@JounQin
Copy link

@JounQin JounQin commented Sep 7, 2019

No description provided.

@mysticatea mysticatea added the question label Sep 7, 2019
@mysticatea

This comment has been minimized.

Copy link
Owner

@mysticatea mysticatea commented Sep 7, 2019

Just out of curiosity, why do you want to ignore that in try statements? If the path is not static, the rule ignores it already. I'm not sure why you want to do with conditional way for static stuff.

@JounQin

This comment has been minimized.

Copy link
Author

@JounQin JounQin commented Sep 7, 2019

I want to detect whether the package exists and resolve different configurations.

@mysticatea

This comment has been minimized.

Copy link
Owner

@mysticatea mysticatea commented Sep 7, 2019

Thank you. But I'm still not understanding why the statement is needed. How does the extraneous package come? It looks fragile approach, e.g. people may have the package for another reason from the assumption of your package.

Anyway, all try statements are not for require.resolve and it's hard to distinguish try statements for require.resolve or not. And it looks rare cases, I don't see enough pros to implement it.

@JounQin

This comment has been minimized.

Copy link
Author

@JounQin JounQin commented Sep 7, 2019

That OK, I'm just sharing my thoughts here.

And another example could be shareable configurations like https://github.com/1stG/configs/blob/master/packages/eslint-config/overrides.js#L11. I'm trying to simplify our configuration usage in different projects with fallback preset. I don't know is that a common pattern.

@JounQin

This comment has been minimized.

Copy link
Author

@JounQin JounQin commented Sep 7, 2019

close for now, disable the rule inline case by case is fine enough.

@JounQin JounQin closed this Sep 7, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.