Zipped Static Resources editability in IDE

[Adam Stepanek]

Hi Scott,

‌

I was just thinking if it would be possible to be able to edit the zipped static resources inside IDE. For example, currently we have Experience Site assets such as css and img zipped in single static resources. And in IDE it is saved as .resource, in fact they are just .zip files. And what I mean is to have the folder structure in IDE at least for view, so we can search for example in the resource. Better to be able to update those files like a regular files.

‌

‌

[Scott Wells]

Hi. Assuming this is in a metadata format project (i.e., the pre-SFDX project format), you can use IC2's support for static resource bundles to work with archive-type static resources in an extracted fashion. You will probably want Use separate source root for static resource bundles enabled, and then you can right-click on a .resource file that is actually a .zip file and use Illuminated Cloud > Convert to Static Resource Bundle to work with its contents directly in the IDE.

Let me know if that's not what you're wanting.

[Scott Wells]

I'm going to resolve this assuming that's what you're needing. If not, please reopen and specify how what you're requesting differs from the existing functionality.

[Adam Stepanek]

Hi Scott, this is exactly what I wanted, but I am facing a different issue now. If I deploy the folder manually from IDE, it gets correctly deployed to sandbox, but what it goes through CI/CD (Travis) we get this error.

2.  staticresources/PartnerPortalAssets.resource-meta.xml -- Error: Required field is missing: content

Adding <content></content> manually did not help.

‌

Is there a way out of this, or we have to switch back to .resource structure?

‌

[Scott Wells]

Hi. All static resource files must have a .resource-meta.xml file which specifies the content/MIME type of the associated file, e.g.,

<?xml version="1.0" encoding="UTF-8"?>
<StaticResource xmlns="http://soap.sforce.com/2006/04/metadata">
    <cacheControl>Public</cacheControl>
    <contentType>application/zip</contentType>
    <description>Bundle</description>
</StaticResource>

Of course, the value for contentType will vary based on the associated file type. The example above is for a static resource bundle stored in .zip format in Salesforce and as an extracted directory in the source format project.

I take it that was missing from some of your .resource-meta.xml files?

[Adam Stepanek]

Unfortunately that is not the case, after converting to bundle I’ve ended up with this

eLearningPortalResources.resource-meta.xml

<?xml version="1.0" encoding="UTF-8"?>
<StaticResource xmlns="http://soap.sforce.com/2006/04/metadata">
    <cacheControl>Public</cacheControl>
    <contentType>application/x-zip-compressed</contentType>
</StaticResource>

and the folder eLearningPortalResources.

[Scott Wells]

I’m not sure what you mean by “that is not the case”. The meta.xml file includes a contentType element, just of a different value than the one in my example. That should be a valid content type, but you might try changing it from application/x-zip-compressed to the more standard application/zip and seeing whether that resolves the deployment issue. If it doesn’t, I’d recommend that you reproduce the issue using the Salesforce CLI directly, e.g., sfdx force:source:deploy ... and, assuming that fails in the same manner (it should as that’s all IC2 is doing), you’d need to log an issue with Salesforce.

[Adam Stepanek]

Deploying through IC2 is not a problem, the issue appears when deploying through TravisCI, not sure how the deployment is done there tho. Looks like they are not aware of the possibility of not having the eLearningPortalResource.resource file and having just the folder, together with the meta.xml file.

Thanks for your time, we moved back to the .resource structure, so you can close this.

‌

[Scott Wells]

Ah. I don’t have any real insight into TravisCI, but I can’t imagine that it doesn’t support source format static resources. You might follow up with them as it’s probably not a good idea to have .resource files in an otherwise source format project structure. Such a hybrid format may confuse other tooling leading to various issues working in the project.

[Adam Stepanek]

I’ve found out that we are still deploying using ant, could this be related?

[Scott Wells]

Yep, that would do it. The Force.com Migration Tool, aka the older ant-based deployment tool, is completely based on direct API calls against metadata format files. If you wish to use the newer source format, you’ll need to switch to a tool that expects that format, either the Salesforce CLI directly or a tool built atop it (or a tool that natively understands source format).

‌

[Adam Stepanek]

Hi Scott, we switched to sfdx, and now we are deploying using this command sfdx force:mdapi:deploy -w 120 -g --deploydir $DEPLOYDIR --targetusername ORG --testlevel $TEST_LEVEL $CHECK_ONLY.

Despite that, the issue still persist. We’ve set it up according to this https://github.com/forcedotcom/sfdx-travisci

error:

ide:

‌

[Scott Wells]

The force:mdapi:deploy/retrieve commands are the equivalent of the Ant targets and work in metadata format. You should use force:source:deploy/retrieve to work with source format projects.

[Adam Stepanek]

Hmm, I see, but to run that I need to have sfdx source format project. I found this force:mdapi:convert which allows me to convert metadata project to source format but that results in another issue during conversion. I assume that our time using metadata format is getting to an end :D. As of now I don’t see other way to make this work. Thanks for your patience Scott.

[Scott Wells]

I’m sorry…I’m confusing two issues here where the other is from a user who has recently converted to source format. My responses back to “Yep, that would do it” are based on that confusion. Again, apologies for going a bit sideways there and any time/effort lost as a result.

So just to clarify, there are two ways that IC2 handles resource bundles in metadata format projects: 1) in-place in the staticresources folder; and 2) extracted into a separate resource-bundles source root. You can configure which you want to use here:

https://bitbucket.org/RoseSilverSoftware/illuminatedcloud/wiki/User_Guide/Configuring_Application_Settings#markdown-header-validation-and-deployment

specifically the Use separate source root for static resource bundles option. I would recommend that you enable that option because there are no (known) external tools that know how to deploy in-place bundles in a metadata format project.

Once you do that, you’ll need to update your automated build scripts to create the actual .resource files for each directory under resource-bundles so that it’s deploying the latest version.

Let me know if what I’ve said above doesn’t make sense.

[Adam Stepanek]

So if I understand this correctly, even if we switched to source format and would deploy using force:source:deploy, we would still have to create the actual .resource files for every bundle before deployment?

[Scott Wells]

No, sorry if that was confusing. In source format, the CLI’s force:source:deploy/retrieve commands take care of converting in-place resource bundles to/from .resource files automatically. There was no first-class notion of that in metadata format, though, just a consensus among certain tools (IC, MavensMate, and a few others) around how resource bundles would work, i.e., that archive-type static resource files would be extracted into a resource-bundles directory as a peer to the normal src directory so that you could work directly on their contents. Those tools would also take care of conversion to/from during deployment/retrieval, but any external tooling, e.g., ant for the CLI’s force:mdapi:deploy/retrieve would need help in the form of something that creates .resource archive files from those directories on deployment and extracts them on retrieval (if you retrieve via an external script).

So if you want to work with resource bundles, i.e., extracted archive-type resource files, you must either augment your metadata format deployment scripts with a pre-processing step to create the .resource files from your resource bundle directories or you must move to source format which will do it all for you.

Please let me know if that doesn’t clear it up for you.

[Adam Stepanek]

Thanks for clarification, so we will try to proceed with the sfdx migration. Thanks again for your support :)

[Scott Wells]

My pleasure. Yes, I think unless there’s a concrete reason not to do so, that would probably be a worthwhile investment. In addition to native support for resource bundles, there are other advantages to source format such as SObject metadata decomposition and much more flexibility in terms of how you organize your project directory structure. It also allows you to use scratch orgs as part of your dev/CI/CD processes since you’re already working with the on-disk format required by the CLI commands for scratch orgs.

Don’t hesitate to let me know if you have other questions as you work through that migration.

[Adam Stepanek]

Thanks, Scott, for your support, we’ve successfully converted the project to source structure and the resources are behaving as we wanted.

[Scott Wells]

That’s great to hear! I think you’ll be very happy with the returns on that relatively minor investment going forward. Thanks for circling back to let me know.