Recommended process to deploy unpacked Static Resource contents

[chexxor]

I'm trying to figure out the workflow of editing and deploying the contents of a static resource. The zipped-resources doc says:

1. Open a *.resource file
2. Choose a file inside the resource's unpacked directory
3. Deploy *.resource file using the ApexDeploy command

I am having problems with step 3. I open the "$PROJECT_DIR/resources-unpacked/MyResource.resource/app.js" file in a buffer in vim, then run the :ApexDeployOne deploy command, which tries to deploy that exact file. This gives me an error: no valid files in C:\Users\Alex\AppData\Local\Temp\VIFE452.tmp-fileList.txt (it contains "resources-unpacked/MyResource/app.js").

I'm guessing I'm doing this wrong. I'm guessing I need to deploy the "src/staticresources/MyResource.resource" file. Yeah?

It looks like the only way to do that is to manually type that path into the :ApexStage command, then do :ApexDeployStaged deploy, right? This seems more complicated than it should be. :3

What do you think about this proposed change? - Change the :ApexDeployOne command to check if the current file is in the "resources-unpacked" directory, and map deploy requests to those files to their corresponding "src/staticresources/*" file? For example: I tell it to deploy "resources-unpacked/MyResource.resource/app.js", but it actually generates a command to deploy the "src/staticresources/MyResource.resource" file.

[neowit]

Hello @chexxor,

Are you having problems working with unpacked zipped content and deploying it with all :ApexDeploy<...> and :ApexSave commands or only the :ApexDeployOne?

Current version of :ApexDeployOne is not suitable for deploying files extracted from zipped resources because it tries to deploy the exact file which you have in the currently open buffer, while for zipped resource your open buffer will normally contain one of the files inside the Zip.
Every time you do :w on the file under resources_unpacked/<resource-name.>resource the plugin updates corresponding (zipped) <resource-name>.resource file. So when you do :ApexDeploy it will notice that <resource-name>.resource is modified (because it was updated when you did :w on a file under resources_unpacked), and will include it to the list of files to be deployed as usual.

Does this make sense?

[chexxor]

My understanding agrees with your explanation, which is good. My issue with this is that I only want to deploy one static resource, rather than everything in my project. AIUI, :ApexDeploy will try to deploy the entire project.

I checked the docs for the :ApexSave command after you mentioned it just now and it seems to be close to what I'm looking for. However, I really like the "Save and deploy this file I'm working on" behavior of :ApexDeployOne. I have it mapped to <S-S>, so I can do <C-S>, <S-S> to save and deploy it. To preserve this workflow for static resource development, the :ApexDeployOne command would need to be changed, as I've described above.

[neowit]

:ApexDeploy will try to deploy the entire project.

both :ApexDeploy and :ApexSave only pickup files modified since last deploy or refresh. i.e. in most cases this is not going to be entire project. For entire project we have different commands.

The only difference between the two is that :ApexDeploy uses Metadata API, while :ApexSave tries to use Tooling API, and only falls back to Metadata API when Tooling one cannot be used.

If you are using vim plugin for a day-to-day development (in Sandbox or Dev Org) then I would expect you to use :ApexSave command most of the time. Something like this:

1. you edit some files, call :ApexSave - it deploys modified ones
2. you edit some more files, call :ApexSave - it will only deploy files modified since last :ApexSave (assuming you did not call any Deploy/Save/Refresh commands in between)
   if the only modified files (since last deploy/refresh) are the files under resources_unpacked/MyResource.resource then deploy/save will only pickup the corresponding MyResource.resource file.

Does this help? Or your workflow mandates you to save a single file at a time for some reason?

[chexxor]

Ah, that's interesting. I'll double-check the docs and perhaps propose a change to clarify.

I'd like to organize and summarize the commands in the README file - what do you think? Would you prefer that be done in the vim doc file instead? Due to how it's presented on the project's site, the README is the first place I look to get an overview of how to use it. Then, to get detailed info, I would look in the vim doc.

[neowit]

Any help with the documentation is always very welcome.

I think current version of README is too long and may benefit from some reduction/re-wording. Actual documentation should be in vim doc file as for all other vim plugins.

[chexxor]

I've been busy with personal stuff for the last few weeks. I still intend to spend time on this.

[chexxor]

@neowit - What do you think about putting the "resources_unpacked" directory name behind a variable, perhaps named "g:apex_resources_unpacked_dir_name"? We can use the "resources_unpacked" string as a default value if it isn't defined. If like this, I can use vim-force.com to edit my MavensMate projects, which use "resource-bundles" as that directory's name.

[neowit]

Hello @chexxor
Technically putting the "resources_unpacked" directory name behind a variable is not a problem, but making it work in various vim configurations may be challenging due to resources_unpacked path used in ftdetect/vim-force.com.vim. There is no guarantee that ftdetect script is loaded after your variable has been loaded.

With regards to the use case you mentioned - I do not know how MavensMate tracks changed files, but if you edit and deploy same project from two different tools then you most certainly will get all sorts of weird conflicts.
On the other hand I might have misunderstood your use case. Can you elaborate what sort of workflow you had in mind?

[chexxor]

At work, we're using MavensMate, which is not too uncommon, I believe. Occasionally, I want to open up that project in Vim and make edits, because MM has problems sometimes, or I just want to practice Vim.

MM unpacks the resource bundles into a "resource-bundles" directory. It's the same as vim-force.com does, but the directory name is different. If vim-force.com can't be configured to use that directory, then I can't work on my employer's JS projects with it. :-/

MM is a SublimeText plugin, and it seems like SublimeText will auto-reload the editor's buffer immediately after the underlying file changes. I don't know how that works. I believe Vim can be configured to do something similar.

I've been playing, and the following changes seems to work and is close to what I'm looking for. Like you said, though, the order of variable definition is a source of problems. I am still working on this.

- au! BufRead,BufNewFile */resources_unpacked/*.js set filetype=apexcode.javascript | set syntax=javascript
+ execute "au! BufRead,BufNewFile */" . g:apex_resources_dir . "/*.js set filetype=apexcode.javascript | set syntax=javascript"

and my ~/_vimrc like this:

let g:apex_resources_dir = "resource-bundles"

Update: Yeah, I see what you mean now. All plugin files are loaded before the .vimrc file is loaded, so we don't know any user-configurations until that time. It seems the only time is to have the user's .vimrc source one of this plugin's files after this configuration is done. It looks like you instruct this in the installation instructions: runtime ftdetect/vim-force.com.vim. Is that the purpose of this file? To be set a of post-user-config commands to run?

[neowit]

ftedetect is often used to override default vim file type detections. Without it all SFDC related files (with minor exceptions) would be detected with incorrect file types.
e.g. MyClass.cls would be detected as .st (Smalltalk) file.
see :help ftdetect you want to know more about ftdetect.

If the changes you made work for your current config then great, there should be no harm in using those. Inclusion of this type of change in the main plugin may not work well for many users. So we will have to come up with a better idea or park it for now.