Hey Minko
for the following component I do get a linting error:
@Component({
selector: 'dog',
templateUrl: './dog.component.html'
})
export class DogComponent {
@Input()
dog: Dog;
}
Rule:
"component-selector": [
true,
"element",
[],
"kebab-case"
],
Linting result: The selector of the component "DogComponent" should be named kebab-case (https://goo.gl/mBg67Z)
In my opinion, the selector dog is perfectly kebab cased. When I change the selector to "d-og" it does work - but shouldn't it be possible to have selectors without dash for components that are named totally lowercase?
Thanks and Kind Regards
Joachim
Yes, the error message is not correct.
Is it only the error message? Or shouldn't there be any error at all?
Probably the rule doesn't validate the selector properly.
Actually, this is against the standard - Web Components must have at least one dash in their name. The error message is not correct. I'll update it to:
The selector of the component "DogComponent" should be named kebab-case and include dash
I know it's a bit more restrictive so we can come up with a better solution in future.
@mgechev
Can you make the requirement for the dash configurable? We want the casing to be validated, but the naming of our components can't require a dash due to several "special use" components we have. That leaves erroneous messages in the log that are just in the way. We would remove this rule to clean up the log, but need the validation for the other components.
@HFTSOL What about disabling the rule with tslint-aware comments in the special cases?
@HFTSOL the dash is required for all custom elements. As @lazarljubenovic suggested you can disable the rule with a comment.
@lazarljubenovic @mgechev
Given that the idea of Linting is to analyse and audit the code externally, it seems like a violation of the separation/pattern to make the code "aware" of, or dictate to, the auditor.
It would be great if the rules could account for the desired modification of the typical standard. We still want the name validation on all selectors, but we can't have the requirement for the dash since it is in not required for our custom elements. I understand if it's industry standard, but you already have a significant number of alterations that allow for bending of those standards to account for custom scenarios. I don't see that this option would be out of place.
I hope this isn't asking too much. We appreciate what you've built so far and would like to be able to fully utilize it in our applications.
@HFTSOL That's why you have config files like tsconfig.json right?
what if the app location is replaced by [ ] in component-selector
change dog to app-dog
app-Dog is wrong too
just app-name by Lower Case
Any chance this will be happening? I don't want to use a prefix, as it doesn't make sense to use one in my application and the linting error is really annoying.
It doesn't appear they intend to allow people to use standards that differ from their own. For this reason, and many others, I just disable tslint entirely on every project since it causes more problems than it solves.
It is not about a standard that differs from their own.
It is about THE standard for custom element naming.
You can find it here: https://html.spec.whatwg.org/multipage/custom-elements.html#valid-custom-element-name
They contain a hyphen, used for namespacing and to ensure forward compatibility (since no elements will be added to HTML, SVG, or MathML with hyphen-containing local names in the future).
PotentialCustomElementName ::=
[a-z] (PCENChar)* '-' (PCENChar)*
A mi me aparec铆a ese error cuando borraba la imagen de Angular en el app.component.html, pero me fui al app.module.ts y lo volv铆 a compilar si efectuar ning煤n cambio y se desapareci贸 el mensaje.
What is the tslint rule's name for disable?
it's component-selector
Most helpful comment
@lazarljubenovic @mgechev
Given that the idea of Linting is to analyse and audit the code externally, it seems like a violation of the separation/pattern to make the code "aware" of, or dictate to, the auditor.
It would be great if the rules could account for the desired modification of the typical standard. We still want the name validation on all selectors, but we can't have the requirement for the dash since it is in not required for our custom elements. I understand if it's industry standard, but you already have a significant number of alterations that allow for bending of those standards to account for custom scenarios. I don't see that this option would be out of place.
I hope this isn't asking too much. We appreciate what you've built so far and would like to be able to fully utilize it in our applications.