Allow flexible directory structure (pseudo-packages, test classes in separate source root, etc.) for metadata

[Scott Wells]

Allow users to configure modules using multiple source roots including Test source roots and have Illuminated Cloud deploy to Force.com from these source roots and reconcile back into the appropriate source roots on retrieve.

Also allow arbitrary sub-foldering for metadata, in particular the classes, triggers, pages, and components folders. On deployment add a comment denoting the "package", e.g.:

//package com.mycompany.controller

or:

<!--package com.mycompany.controller-->

and on retrieval use that comment to place retrieved metadata in the correct sub-folder if specified.

Also for static resources, sub-folders could be used for automatic archive creation on deploy and archive expansion on retrieve.

[Laerte Sousa Neto]

I believe that having flexible directory structure built into the plugin would be very helpful but handling static resource of zip/archive format is a feature in much greater need. When using JavaScript Frameworks to develop custom Salesforce Front-End pages, zipped files are the best alternative to handle a complex structure and is frequently used among developers. I personaly have used it extensively in order to move away from Visual Force and use the latest Web Frameworks out there such as AngularJs, NodeJs, RequireJs, and Bootstrap without much interference from the Salesforce platform limitations.

Flexible directory can already be done with third part software such as DSynchronize while modifying zipped Static Resources only works with MavensMate Resource Bundle. Since Jetbrains Intellij is a much superior IDE than Sublime, if Illuminated Cloud offered the same benefits plus more that of MavensMate, there would be no reason for Force.com developers to stick with MavensMate besides for the fact that it is free.

[Scott Wells]

Created issue #131 for the static resource bundle aspect of this story. This story is now for only flexible directory structure support.

[Jonathan Toland]

I was about to discourage you from this. But it has a really compelling use case. You'd open up the open source ecosystem to Salesforce. If I wanted to use SLDSX or whatever I could just put it in a git submodule and let IC merge them without having to formally install a package. You could even set up a hierarchy for conflicts (which directory wins). I love this idea!

[Scott Wells]

Yeah, this one is actually near-and-dear to my heart. Coming from environments that allow you to organize your source code however you want, I find the basically flat directory structure of a Force.com project frustrating once the number of source files reaches a certain point. Let the developer(s) organize things however makes the most sense and then have the tools reorganize to match the deployment requirements. I also really like the idea of IntelliJ's formal distinction between production and test source files and would like to be able to apply that to Force.com projects for a better separation of concerns (even if it's just in the file system). Having said all that, this one is definitely behind not just Lightning but several other enhancements...

[Jonathan Toland]

I forgot to mention the tricky part is associating files in Salesforce with their local paths. I suppose you could just maintain a XML alongside package.xml though. Totally agree on priorities!

[Jonathan Toland]

I'm building a temporary solution to this using Node and MM CLI. When I get down to brass tacks I'll confer with you about metadata format.

[Scott Wells]

Let me know. As noted above, one relatively easy way to know how to reconstruct the directory structure is to include the information in the files themselves in the form of marker comments. I strongly prefer not to have to pollute the source files, though, so what I'd really prefer to do is maintain that information in the IC configuration files that would be checked into SCM and shared among the team.

[Scott Wells]

Issue #432 was marked as a duplicate of this issue.

[Scott Wells]

Issue #620 was marked as a duplicate of this issue.

[Scott Wells]

I'll be folding Saleforce DX support into the product in the next week or so. Since Salesforce DX includes a flexible folder structure as a first-class consideration, I'm considering resolving this since a custom solution is always going to present challenges. It won't work with other tools that expect a certain directory structure, e.g., anything that uses the metadata API for deployment of a standard package directory structure.

There are quite a few watchers on this enhancement request, though, so I'm curious to hear how important it is for this type of functionality to exist for traditional projects vs. Salesforce DX projects. I understand that not everyone will be moving to SFDX immediately (in many cases, cannot do so due to gaps in the initial feature set), but my feeling is that the amount of work that would go into this feature vs. the potentially short viability for it since hopefully most people will be on SFDX within a year or so of its launch makes it much lower priority than things like refactoring, smart client-side code inspections and intentions, etc.

Thoughts?

[Scott Wells]

Issue #1080 was marked as a duplicate of this issue.

[Scott Wells]

Removing version: Unassigned (automated comment)