Tslint: new rule: no-magic-strings

[piotrwitek]

There is already no-magic-numbers rule, so I think it would be nice to add a sibling ruleno-magic-strings, which would have the same functionality as former one have for number, but obviously concerning string literals.

Is this proposal acceptable by tslint team?

A context for the use-case:
When adding new features to the view layer developers are tempted to use inline strings instead of looking for existing labels in texts/translations dictionary, this opens up a surface for bugs to slip through the code review process and adds an unnecessary burden on reviewer.

To make it practical by default it would need to only work in a specific conditions (e.g. textContent of html node etc.). Moreover it would need an investigation of other relevant use-cases to get the optimal default behaviour and useful configuration options.

EDIT:

For those having similar concerns and looking for a solution there is a JSX specific rule (in tslint-react) that try to address hardcoded strings in view layer: jsx-use-translation-function

[adidahiya]

I don't think this would really be as widely applicable as no-magic-numbers is. "Magic strings" show up all the time, in my experience, and they're generally ok.

[Jessidhia]

We do now have string enums in TypeScript, which should help deal with the magic string problem.

The hard part is, how to tell a magic string from a regular string that happens to be written inline.

[piotrwitek]

@adidahiya I don't argue if they are widely applicable or not, there are already a few existing rules that you could say the same thing about them and still, they exist.

Basically I want a specific folder in a project containing only functional view components, to use only dictionary variables and do not allow in-lining any string values.
This could greatly help with refactoring of older views containing magic string, but would also help all the team members to remember to use dictionary and not to cut corners with inline strings when implementing new views, this also will have an effect on code review concerns in the end.

So do you think this is a user-land concern and should be better implemented as custom rule?
Or maybe might be useful for such use cases and would be cool to be included in tslint.

[adidahiya]

@piotrwitek you're right, you could argue that a number of the current core rules are not applicable to everyone. But I have to draw a line somewhere. At the moment, I am reluctant to add no-magic-strings to the core rule set unless there is high demand from the TSLint community.

[piotrwitek]

@adidahiya that's fine, I totally understand your concerns 👍
In the meantime I'll try to come up with a custom rule and come up again if it turn out as something useful to a wider audience :)

[JoshuaKGoldberg]

Looks like there hasn't been much interest in this. Closing as declined.

If it comes up that this is actually needed, we can always re-open.

[goldingdamien]

Would like to see this implemented.
Probably not suitable for the core rules set though.