-
-
Notifications
You must be signed in to change notification settings - Fork 356
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
No template literals in normal strings #15
Comments
Yeah. Doesn't have to happen often to be useful. Might want to wait on this though (from linked issue):
|
It's now closed, sadly. I'd love to be able to use this rule. |
Alright. Let's do it then. |
@sindresorhus it'd be awesome if it could be done standalone, and made a dep of this one, so i can use it in other packages without having to bring in this entire package :-) |
You wouldn't get much less by having a standalone module (there a not a lot of dependencies... yet), and maybe you'll want all the awesome rules that it has and will have? :D More seriously, to me, it's a bit of a pain to create a new project for it. I agree that you might not want all the rest, but maintaining-wise, it's simpler to have it in a project that is actively maintained by several people, not in a corner somewhere. I proposed to add it here because this is a collection of various rules, and what you asked for is kind of a specific rule, with no existing plugin (afaik) it could get included in. Then again, if we write this rule, you're free to copy it in a new repo and use it as you see fit. |
I use If the authors don't mind, then once written, I'd be happy to spend the few minutes required to create a new project, and would be happy to copy the code and share ownership/maintainership of it, especially if this module could pull it in as a dep. |
Maybe we should build this project as a monorepo? Split each rule into its own package? It would be interesting to explore what AVA and XO could do to enable monorepo development:
|
Can be interesting.
Does AVA already do something monorepo-like, or are you suggesting it could start doing something in that vein? If so, I'm curious as to what parts of it. |
I'm really not a big fan of monorepos. At this point it would seem like a premature complication. It would also add a lot of overhead. I think the rules we have now makes sense in one package. We currently have a nice setup with tests, docs and code coverage. I don't really see the problem depending on this plugin, even if you only want one rule. We currently only have 4 tiny dependencies. Dependencies matters less in a dev environment.
I would rather fix that module. It should have an ignore option. |
Closing as it's being integrated in ESLint core rules eslint/eslint#6767 |
eslint/eslint#5850
Do we want to create a rule for this here?
I don't think it happens often but can be useful, and we might as well put it here as we have/want plenty of different type of rules.
The text was updated successfully, but these errors were encountered: