Add ls-lint to sfdx projects

[AllanOricil]

Is your feature request related to a problem? Please describe.
No

What are you trying to do
Standardize the way sfdx projects enforce file/directory naming conventions.

Describe the solution you'd like

• sfdx projects must be created with ls-lint
• sfdx projects must have a standard set of ls-lint rules.
• rules must be overwritten
• must be called by an sfdx hook (pre commit|push prefarably)
• include ls-lint in the lint script. I want to run es-lint and ls-lint when typing npm run lint
• it could be released as a plugin called @salesforce/plugin-ls-lint and later, based on telemetry data, you can decide if it makes sense to add it, or not, in the list of core plugins.

https://ls-lint.org/

You could create a new package that bundles ls-lint with your pre defined set of rules, and then add it in the dev dependencies of sfdx projects.

Benefits:

• less time reviewing PRs to check if files and directories are following naming conventions
• ease project onboarding
• avoid deploying metadata that arent following naming conventions

Describe alternatives you've considered
I can add ls-lint to every sfdx project I work on... but I would have to spend time convincing people about its benefits, and every sfdx project could end up having different set of naming conventions.

Additional context
N/A

[github-actions[bot]]

Thank you for filing this feature request. We appreciate your feedback and will review the feature at our next grooming or sprint planning session. We prioritize feature requests with more upvotes and comments.

[git2gus[bot]]

This issue has been linked to a new work item: W-13479253

[iowillhoit]

Thanks for the feature request, it is now in our backlog. Some the folder structure ls-lint config could be created from the metadata registry.

[AllanOricil]

I can do this if you don't mind.
Is there a list with all possible metadata types and patterns the metadata API expects?

[mshanemc]

Can you give some examples of what rules you'd want to create?

[AllanOricil]

@mshanemc @iowillhoit @AnanyaJha @cromwellryan anybody else that works with dx

It is the same issue that linters and formatters fixed a long time ago, but for file and folder names.

You can come up with rules for all types of metadata that Developers/Admins have to manually name it, and that is used as the Metadata File name. It bothers me so much to see different devs/admins following different naming conventions and then WASTE project time reviewing PRs just to make it "right" (means follow project's naming conventions, please).

Considering file names, these are some of the possible patterns that are commonly used but not strictly followed, which require some discussions (another source of waste of time) between team members to define a naming convention for files, and project structure. Discussions similar to those that happened before code linters and formatters were invented, but for file names and directories.

Apex

non test class:

{prefix_}{class_name}: ABC_MyClass

test class:

• {prefix_}{class_name}Test`: ABC_MyClassTest

trigger:

• {prefix}{sobject_name}Trigger: ABCSObjectNameTrigger

Sobjec

• PascalCase: MyPrecious

Lwc

• kebab-case: my-cool-lwc
• PascalCase: MyCoolLwc
  ...

SObject Validation Rules:

• PascalCase: MyAmazingValidationRules

List Views

• PascalCase: MyPreciousListViewForMyLovelyCustomer

Permission Sets

• PascalCase: GiveMeSomePower

You get the idea.

FFLlib Enterprise Patterns

You can also take a look at the Enterprise Patterns from the Financial Force Library (fflib), and the FFlib team will be able to provide their own Package (like Airbnb does for prettier and eslint) with their set of rules.

Salesforce can create its own "recommended" patterns as a package. Then devs/admins can configure as they like for their project. Ask around the community to vote for each rule you create. Maybe you can create a new public github project to enable this discussion.

People won't also need to waste their time explaining new team members (project onboarding) how to name metadata correctly.

Different Consulting Companies won't bring their own patterns to projects and make it ugly.

Metada that have character limits for its name will be respected before a deployment. Meaning it can also save time by avoiding running a CI automation that we know it will break because a metadata does not follow platform rules. And we all know that Salesforce Metadata deployment/validation jobs are extremely slow.

[AllanOricil]

Ask the community what they think of it