Quick & Small SFDX: force-app/main/default can be something else!
When you get started with SFDX projects and hands-on modules, you’ll quickly notice that all the examples use force-app/main/default
as the project directory. It also matches with the SFDX default project structure. If you ever wondered if you can have some other folder names and if it affects the SFDX behavior, this article is for you.
Quick answer to the previous question is yes; you can change the folder names and it does affect SFDX behavior.
Why force-app/main/default?
By default, SFDX need some folders to start executing the commands. force-app
is the default directory of the project. main/default
is the default directory for SFDX to work with metadata.
Changing force-app
to something else
You can change the app folder name, as long as you change the sfdx-project.json
file to go along with it. You can have many folders in the project root folder, but only the folder directory noted as "default": true
under packageDirectories/path
section in the json file will be acknowledged as the folder to perform SFDX commands related to source pull.
This can be configured however you and your team want to use, especially for teams with multiple packages in a single sfdx project.
- Leave the initial
force-app
folder as ‘temporary place holder’ so you can pull down metadata there and relocate pulled down files into correct package folders. In this case having theforce-app
folder listed in .gitignore file will be useful to keep your source tracking clean. - Or update the project json file to make the target package folder to be default. You won’t need to relocate all the files if you are dealing with pulling down handful of metadata from scratch orgs. In this case it will be crucial for each members to remember which package they are working on and updating project json file as needed. Also keep in mind that if you pull down a new metadata, it will create (if the path doesn’t exist) and pull sources in the
main/default
folder.
Changing main/default to something else
Any metadata file in its respective metadata folder will be acknowledged for source push/pull along with other sfdx commands. (ex. Apex class files must be directly under classes
folder) But the metadata container folders can be nested under any folder structure inside the package directory.
This is, in my opinion, somewhat useful if you have to have multiple functionality in a one big package, you can have separation between the metadata and keep each folder relatively smaller than it could have been.
> Edit 3/23 : Based on my most recent testing, all the subfolders within a package directories gets deployed at the same time.
I hope this was useful to someone. I found out about those features by testing out SFDX myself, playing around the sfdx-package.json
file as well as googling and reading documentations. Don’t be scared to start a new sfdx project and play around! Change folder names, create packages/package versions and define multiple dependent packages. You can always get a new playground from Trailhead, and make it a DevHub if you’d like to keep your org/developer org clean from your testing. Keep on rockin’!