7

Say I create an SFDX project with sfdx force:project:create...

it creates a directory structure, including a folder structure to hold all the development metadata: [ProjectName]\main\default

Now, when I'm pulling metadata from an org (scratch or sandbox) directly into the project using CLI, it does a handy job of sorting the metadata categories into folders. Within the default folder, it will create an objects folder, layouts folder, classes folder, etc, all automatically.

HOWEVER, when I use CLI to create metadata directly inside my project, like say an apex class, I need to specify the destination directory.

I'm wondering... is it important that I know the automatically created folder structure for my metadata components when it comes to deploying my project? Can I just stick all my files in main without worrying about category folders? Is there a way to generate the desired folder structure for my project at the time of creating the apex class, without manually creating the classes folder myself?

1 Answer 1

1

Good questions. Can you work without the folders - perhaps. Think you will have to experiment and check that the push/pull to/from as scratch org works fine and that the sfdx force:source:convert to move to MDAPI format for deployments into non-scratch orgs works fine.

The sfdx-falcon-template project breaks the tree up in a way that suggests there may be flexibility. But pulls from a scratch org always go into the default tree. This is an example of the trouble you can run into when not using the de-facto conventions because the tools are primarily used and tested by people following those conventions.

We use the conventional folder names when using SFDX. Pretty easy to do through e.g. VSCode.

7
  • Just tried it out - turns out as long as your created classes are sitting in the project metadata subfolder, they doesn't need to be organized into folders to push to orgs properly. It can't sit in the parent projectName folder, but as long as its in the subfolder with the same projectName, it doesn't need to be in main or default...
    – smohyee
    Commented Aug 14, 2018 at 13:36
  • @smohyee But for what operations? Can you push/pull with the org and convert from/to the MDAPI format?
    – Keith C
    Commented Aug 14, 2018 at 13:38
  • I was referring to force:source:push, after I've created an SFDX project and used force:apex:class:create to create an apex class file in the project directory. It didn't reorganize the files into a folder structure or anything, but it pushed just fine. I was also able to pull an unmanaged package into the project and convert the unzipped folder using force:mdapi:convert, which added the metadata to the default folder and created the folder structure automatically
    – smohyee
    Commented Aug 14, 2018 at 15:34
  • Final thing I tried: after pushing the apex to the scratch org, I deleted the classes from my local folder and tried force:source:pull. However, it didn't recreate the deleted apex in the default folder, or anywhere else. Looking into it, it appears the .sfdx\orgs\[ScratchOrgName]\sourcePathInfos.json file was updated with the former directory location of the apex classes when I pushed. Deleting these entries from the file didn't impact the results of a pull, however.
    – smohyee
    Commented Aug 14, 2018 at 15:46
  • My current goal is to figure out how to pull the apex code from the scratch org back into my local project, despite not having made any changes to the code in the scratch org. By default the pull command ignores unchanged metadata... but if I can figure out how to override that, it'll provide a mechanism to quickly create classes locally, deploy with push, then immediately pull as a way to add them into the default folder structure.
    – smohyee
    Commented Aug 14, 2018 at 15:58

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .