7

I am just curious of what is the best practice, it seems that if I create folders in force-app/main/default/classes and put my classes there everything seems to work fine.

Is this in any manner bad or unwanted in Salesforce development? Can this affect the packaging of the application? Are there any other consequences?

Example:

force-app/main/default/classes/Services/ServiceA.cls
force-app/main/default/classes/Services/ServiceA.cls-meta.xml
force-app/main/default/classes/Services/ServiceB.cls
force-app/main/default/classes/Services/ServiceB.cls-meta.xml

Instead of:

force-app/main/default/classes/ServiceA.cls
force-app/main/default/classes/ServiceA.cls-meta.xml
force-app/main/default/classes/ServiceB.cls
force-app/main/default/classes/ServiceB.cls-meta.xml

1 Answer 1

4

This is a feature that the community has wanted since at least 2009. The ability to organize your code metadata in to folders. It can make finding and managing code easier. Of course, this is only client-side, but it does help organize your code, and you should take advantage of it, especially if you have a lot of classes.

There are three limitations to this that you should be aware of. First, you cannot deploy the same case-insensitive class name from two different folders. Second, you cannot version the same case-insensitive class name in a dependent package of a parent package in the same namespace. Third, you cannot install two packages from the same namespace that contain the same case-insensitive class name in to the same org.

Aside from those three limitations, you can divide your classes folder in any way that makes it easier to navigate your code. Some organizations prefer to group by application (e.g. Marketing, Sales), some by the type of class (e.g. Service, Batch), or some other model that makes sense.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.