Closed daKmoR closed 3 years ago
no-useless-template-literals should not work in property bindings, but it's ok to be in the default for other positions.
Agreed with @OpportunityLiu , I think the rule in principle is fine but having it scan property bindings is likely unintended, and imo should be flagged as a bug.
yup that makes sense.
<div attr=${'foo'}>
should still be invalid, but <div .prop=${'foo'}>
shouldn't (since there's no other way to set it, i.e. you can't do .prop="foo"
).
This issue is still there for eslint-plugin-lit 1.4.0
can you possibly give an example?
there is a test here which passes fine in master:
The change was that the rule is still enabled but will allow properties to be set as literals
<lion-select
name="favoriteColor"
label="Favorite color"
.modelValue=${'hotpink'}
>
Literals must not be substituted into attributes, set it directly instead (e.g. attr="value")eslintlit/no-useless-template-literals
Interestingly enough I get that error 5 times when I hover the squigly line in VS Code.
npm ls eslint-plugin-lit
lion-tsc@0.0.0 /home/joren/code/lion-tsc
└─┬ @open-wc/eslint-config@4.3.0
└── eslint-plugin-lit@1.4.0
I scaffolded the project with npm init @open-wc
--> new project --> web component --> with typescript + linting only
excellent, ive managed to reproduce it with your example.
ill work on a fix 👍
@43081j someone at work ran into this issue, was just wondering if it was fixed yet? If not, maybe reopen?
i wish i knew what i managed to reproduce back in 2021 🙈
I scaffolded the project with
npm init @open-wc
--> new project --> web component --> with typescript + linting only
i did exactly this and added the lion-select
example, all worked as expected.
any chance you can help come up with a repro of where you've seen this happen @jorenbroekema ?
when having html like
the rule will say
${10}
is not allowed here. However, to my knowledge, there is no other way to set the property as a number 10 with a different syntax.setting a specific variable for it seems kinda unnecessary.
I think as a programmer/team you can decide to follow this rule. However, I would not consider this a recommended rule.