Hi Scott,
Salesforce DX will be the future of SF development. https://developer.salesforce.com/platform/dx
You can register to the whitelist here: http://go.pardot.com/l/27572/2017-01-23/6gh89x
Salesforce IDE plugin (pilot) already support the basic command of creating new local source for working with scratch orgs.
This ticket was created so this will be on your roadmap, obliviously more details are needed, so I hope you will be able to enter the pilot.
I will update this ticket with more information if needed overtime.
Thanks!
Thanks for logging an issue, Niv. I've actually been involved in the DX initiative for over a year and have participated in the pilots. I'm already beginning implementation of a DX integration with IC and hope to have a first phase of enhancements ready for release in the coming week. Anyone interested in keeping an eye on progress can watch this issue or keep an eye on the DX Pilot Chatter feed where I'm quite active.
Here's a quick video showing what I'll be posting later today or tomorrow as the first phase of the IC/DX integration:
I'll likely post it here as a pre-release/test build initially rather than an official release to minimize the chance of disruption of non-DX users while I work through any kinks.
Here's a pre-release/test build with Salesforce DX support. It can be installed by using Settings>Plugins>Install plugin from disk against the attached archive. Please watch this video for an overview of the currently supported features. Note that right now IC's metadata retrieve operation still works against a single source root. I'll be addressing that in a subsequent build.
Hi Scott,
I'm doing a standard git checkout of sfdx-simple, and I noticed that it stores the .iml file in the force-app directory. This also happens when I checkout other projects from git. Is there a way to configure this so that the file is stored in the root or .idea directory? Having this file in the sfdx force-app dir breaks sfdx in terminal (force:source:...)
Thanks!
I know I can manually move the file and then edit the .idea/modules.xml file to point to the correct location, but I just want to make sure this isn't some configuration issue with IDEA
Ah, good to know. Should be trivial to fix in the next test build. For the moment you can fix this manually by moving the file to the project root and updating paths in .idea/modules.xml and the .iml file itself.
Just wanted to comment that I installed this build and it worked exactly as the video described ... and it didn't corrupt any of my 'classic' MDAPI/Tooling API projects either .. so extra bonus points for that :-)
I know you have an open discussion with the DX people about how the MDAPI source tree maps to/from the new project structure. We're keenly interested to hear how that turns out since it sounds like we're many months away from being able to go whole hog with SFDX .. so we'll be converting to/from MDAPI trees for a long time still.
Hi Scott, Do you have a DX build with 1.7.8.6? Thanks, Peter
I don't have a second build for DX yet. I've been working on one, though progress has been slowed by a REALLY bad virus that's knocked me out for the past week. I'm hoping to have a second build out on Monday, though, that would include all of the fixes from 1.7.8.6 as well as a bunch of new DX features.
Thank you, Scott! I hope you will defeat the virus very soon.
Note that if you update your sfdx CLI to the latest build, the IC/DX integration will be broken. The latest CLI isn't giving sufficient information to be able to refresh the OAuth access token. I've reported this to Salesforce and hope that a fix will come very quickly on their side. In the interim, if you're trying out the IC/DX integration and haven't updated the CLI yet, please wait until I give an all-clear before doing so.
Here's a second pre-release/test build with Salesforce DX support. The installation process is the same as described above. I've posted another video showing what works now and what doesn't. Please let me know if you have any issues using it.
Hello. Maybe a simple question but how can I test this build? Do I just install it and use this one for my regular other live projects as well? Or do I need a separate installation of intellij? Or do I need a new machine? Or can I just easily switch between installations of this plugin by installing and uninstalling? I don't want to break my other projects in case of emergency :-) Thanks!
Hi, Steven. It's up to you. The test build is generally the same as the standard build but with Salesforce DX support as well. Because of refactoring I've had to do to support both models and the lower level of testing due to these being test builds, it's quite possible that some of the shared features have bugs that aren't in the standard build, but I've tried to minimize that as much as possible. If it means anything, I use these test builds as my own daily drivers. If for whatever reason you do find that the test build has bugs that are interfering with your normal usage, you can always revert to the standard build and use another install of IntelliJ IDEA for the test build.
I would recommend that you wait to install the test build as there are a few fixes and enhancements I've implemented over the past few days that I plan to include in a third test build to be posted later today. One in particular is the result of a recent change to the DX CLI that can cause repeated unnecessary logins. I'll post the test build to this issue when it's ready.
Ok. It helps and reassures to know you just use the test build as your own daily driver. I'll wait for the upload though :)
Thanks and keep up the good work!
Just a quick update...I'm running a bit behind but plan to post a new test build tomorrow with some fixes, performance enhancements, and all of the latest main build stuff.
Okay, here's another test build with preliminary SFDX support. It includes everything that was in today's 1.7.8.9 official release as well as the following improvements to the SFDX features:
sfdx CLI invocations to refresh the access token.Aside from multi-module support, there are no new major SFDX-specific features in this build. In upcoming builds I plan to add the following:
force:source:push.force:source:pull.There are as few bugs in the CLI that need to be addressed before some of these will be possible, though. I've already reported them to the Salesforce folks so hopefully they'll be resolved in the upcoming updates to DX.
Here's another pre-release test build with SFDX support. Note that it still doesn't have any DX-specific enhancements, but it is based on 1.7.9.4 which I released this morning and includes all fixes, enhancements, etc., from that release. I do plan to release an update with more DX-specific features in the next week or two.
Looks like the pre-release broke a few things. I'm no longer seeing DX connections in 1.7.8.9 or 1.7.9.4 SFDX builds when using the pre-release version of the SFDX beta.
Thanks for letting me know, James. Let me take a quick look. While I'm doing so, can you verify that the path to the sfdx executable is still set properly in your Validation and Deployment settings? Those will get wiped out if you install an official release in between, by the way.
Yeah, I just installed the attached build, verified that the sfdx binary path was set properly, and then I was able to see the DX connections. Please let me know if you're not seeing the same thing.
Thanks for the response.
Still not seeing any DX connections after verifying the sfdx binary path. Here's my sfdx binary version:
λ sfdx version
sfdx-cli/5.7.5-05549de (linux-amd64) go1.7.5 sfdxstable
λ sfdx plugins
salesforcedx 40.0.8
Let me know if I can provide any additional information on this.
I'm experiencing the same as James.
$ sfdx version
sfdx-cli/5.7.5-05549de (windows-amd64) go1.7.5 sfdxstable
$ sfdx plugins
salesforcedx 40.0.8
Sorry, I crashed pretty hard last night. I just noticed that my CLI is still on 39.8.1-0. Let me update it to the latest and see if I can reproduce what you're seeing. Could be a change in the input/output format for the CLI that I haven't accommodated. I'll let you know what I find.
Hmmmmm...so I just completely reinstalled and I keep getting 5.6.22 for the CLI and 39.8.1-0 for the plugin:
$ sfdx version
sfdx-cli/5.6.22-f9533ba (windows-amd64) go1.7.5 sfdx
$ sfdx plugins
salesforcedx 39.8.1-0
I'm on Windows, but so is Brad. Is there anything you guys have done to get to the newer version? I'll also post on the Chatter feed shortly.
Okay, I've been chatting with Thomas Dvornik at Salesforce on the Chatter feed and have found a few things. First, after doing a full reinstall, it appears that the binary has changed locations and is no longer under /path/to/Heroku/bin/sfdx but is now under /path/to/sfdx/bin/sfdx, so make sure that you're pointing to the right location. Also, according to Thomas, the latest developer preview version of the plugin is in fact 39.8.1 and 40.0.8 is a pre-release as they're ramping up for TrailheaDX. Do you guys know how you were updated to that version? I'm wondering if they made incompatible changes to the CLI commands and/or JSON output for beta.
It's very possible that we're in an in-between state right now where I won't be able to (easily?) have a version of the plugin that works for folks on the developer preview version and for those on the beta version due to incompatibilities. If that's the case I'll see if I can move to the beta version ASAP and rev for that.
I'll keep you posted on what I find.
Okay, I've now received concrete confirmation that there are breaking changes between 39.x.x and 40.x.x. I'm going to start targeting 40.x.x, but since that's not officially available yet, I might suggest that you roll back your plugin version to 39.x.x until I'm able to do that if SFDX integration is critical to your daily work. Sorry for the nuisance, but there's no good way to have a single build support both...at least not in a way where the investment makes sense for such a short-term change.
I'll post an update that works with 40.x.x here as soon as I have it, but for the moment if you're really needing this, please roll back to 39.x.x.
Thank you, Scott, for all your great work!
Okay, here's a new build that is adjusted for the 40.x.x version of the sfdx plugin. Note that if you're on the 39.x.x version, use IlluminatedCloud-14.zip, and if you're on the 40.x.x version use IlluminatedCloud-14_SFDX_40.zip. For those of you on 40.x.x, please let me know if this build doesn't resolve your issues.
Going forward I only plan to update based on 40.x.x since it reflects the upcoming beta of SFDX.
FYI, I'm making another set of updates right now for 40.x based on the change from sfdx-workspace.json to sfdx-project.json. I'll post the updated build here shortly.
Here's another build for SFDX beta/40.x that takes into account the change from sfdx-workspace.json to sfdx-project.json and the corresponding changes to the casing of key names in that file.
Thanks for the quick fixes Scott. Everything is working for me now! Sorry for my late response, I'm in another time zone.
Thanks for confirming, Brad! Please let me know if you hit any other issues, and I'll hopefully be posting a new build with more SFDX functionality here soon.
Issue #634 was marked as a duplicate of this issue.
Quick update: I'm actively updating the test build for breaking changes in beta. I'm hoping to have a new build in the next few days. I've identified a few bugs in the CLI with validation error reporting, in particular for Lightning, and have reported them to Salesforce. Once those settle and I feel like things are solid for both traditional and SFDX development models, I'll include all of this in official releases.
Here's a new pre-release/test build with Salesforce DX support. This adjusts more fully for the beta, and it also adds source push/pull support as the standard metadata deploy/retrieve behavior from within an SFDX project. For more details, see this video.
Hi Scott,
I watched the video, I noticed in the case were there was a collision (changes on server and local) I didn't see an option for a compare window to be able to merge changes. It seemed like it was just push local to server or pull server to local, in either case you would lose a change?
Yes, you're correct. Right now IC just calls push and pull in the CLI as requested. There's not currently a way to do a selective pull from the server for just the conflicting items to make them available for a diff. I could use the API directly to do that, but the API doesn't know about things like metadata decomposition so I'd have to implement that myself to make it work properly. During the SFDX pilot period several folks asked for a first-class ability to diff/merge conflicts via the CLI (e.g., sfdx force:source:merge or sfdx force:souce:diffconflicts) and I know it's being entertained, so I figured I'd play the waiting game in hopes that it's addressed in the core CLI before tackling it myself. If it doesn't end up getting into the CLI I'll figure out a way to make that same feature available for SFDX projects.
@PeteyB, in my Salesforce projects I always commit to my local git repo before retrieving metadata; that way I can easily compare / diff what is now locally pulled down vs. what I last saved in my repo. This trick might work for you here with SFDX.
Doug, yeah I can see that and usually you'd write code only in IntelliJ so it shouldn't(most cases) be a problem but I like a system that protects you, checks and balances. I don't commit until I have a working version so I can see in the midst of doing things between Scratch and IntelliJ there might be overlap, especially as in Scott's example where you edit the custom object definition in IntelliJ.
Scott, is there a place to ask Salesforce for a diff/conflicts feature for Salesforce DX? Like is there a chatter or a feature to vote for it? Can we make one?
Yes, absolutely. The open beta has a group on the Salesforce Success Community:
https://success.salesforce.com/_ui/core/chatter/groups/GroupProfilePage?g=0F93A000000HTp1
I highly recommend that everyone working with the open beta participate in that group as it's the best way to channel feedback to the folks building SFDX.
Just installed the new test build, and I'm very excited to get up and running with SalesforceDX.
When adding the demo projects from Salesforce, I am having an issue with my session ID when generating the offline symbol table.
This comes up as expected before the pull:
...then this error comes up after it makes some progress.
Testing the DX connection itself appears to work from the Connections config screen. Since it's a DX connection, I can't tweak my login at all (all the fields are greyed out).
Any ideas?
Chandler, there's a known issue right now with session expiration where it's not refreshing the OAuth access token when it should. I've already reported this to Salesforce. The workaround is to run some SFDX CLI command that contacts the server. You could make a token change to a local file and use sfdx force:source:push, or you could execute an anonymous Apex command:
Either way as long as it ends up contacting the server it'll refresh the expired access token and then everything should work fine.
I may implement a workaround in IC for this until Salesforce resolves the issue, but for the moment this manual workaround should do it for you. Please let me know if it doesn't.
Test build for SFDX updated with all changes from official build 1.7.9.7. No new SFDX changes in this build.
Hi Scott, I have sent you the idea.log to your support email. It seems that IC-SFDX-beta 1.7.9.7 cannot retrieve non-DX project when the path to the Salesforce DX executable is filled under the IC Validation and Deployment tab.
After I’ve filled the correct path to the Salesforce DX executable under the IC Validation and Deployment tab, I created a new non-DX project as below. Project name: ic01plsf Project location: C:\0CC\ic01plsf Enabled Retrieve metadata from Force.com Disabled Merge retrieved metadata Disabled Deploy metadata to Force.com Enabled Generate offline symbol table
Module name: 01sucthead Content root: C:\0CC\ic01plsf\01sucthead Module file location: C:\0CC\ic01plsf\01sucthead\modulefile Project format: .idea (directory based)
The IC-SFDX-beta 1.7.9.7 could not retrieve the metadata to the src folder.
Then I set the blank value to the path to the Salesforce DX executable under the IC Validation and Deployment tab as below, then IC-SFDX-beta 1.7.9.7 retrieved the metadata successfully to the src folder.
Does this mean that IC-SFDX-beta 1.7.9.7 cannot detect the current non-DX project but treat it as a DX project? Will IC + DX support non-DX project with one project including multiple modules (each module match to one Production or Dev or Sandbox org) as the current IC official release?
Thank you for your excellent work on IC! Thanks, Peter
Peter, IC will support a project being either for SFDX or for traditional/MDAPI connections. It will not support a single project having modules, some SFDX and some traditional/MDAPI...at least not for now. I did look into supporting that but it got REALLY complex REALLY quickly.
So having said that, are you saying that you have a non-DX project and, with the sfdx binary path populated, retrieve is failing for that project? If so, that's definitely a bug that I'll need to address.
Thank you, Scott!
The above case is the following Project Structure A (a non-DX project with the sfdx binary path populated, retrieve metadata is failing) with the module (only one traditional/MDAPI connection) Content root at a directory different from the Project location directory.
Project location: C:\0CC\ic01plsf
Module name: 01sucthead
Content root: C:\0CC\ic01plsf\01sucthead
Will IC + DX support the following idea project structure?
A. One project includes only one traditional/MDAPI connection
B. One project includes more than one traditional/MDAPI connections (IC without DX supports this)
C. One project includes only one SFDX scratch org connection
D. One project includes more than one scratch org connections with one set of SFDX metadata
Thanks, Peter
Scott, How many different ways IC+DX will support for creating a new SFDX project? Your video showed that one way to do it is to git clone from a remote (maybe local) Git repository. Does IC+DX support creating a blank SFDX project (with simplest SFDX project structure but without actual content) to prepare to run sfdx force:org:create? Thanks, Peter
Is this the same issue? I've been getting this on a non-SFDX project constantly while scanning files to index on IDE load. It won't stop.
2017-07-25 09:32:57,939 [ 397595] INFO - luminatedCloudConnectionConfig - Retrieving org list from sfdx CLI.
2017-07-25 09:32:57,940 [ 397596] INFO - luminatedCloudConnectionConfig - Retrieving org list information from sfdx CLI.
2017-07-25 09:33:00,544 [ 400200] INFO - luminatedCloudConnectionConfig - Retrieving org list from sfdx CLI.
2017-07-25 09:33:00,545 [ 400201] INFO - luminatedCloudConnectionConfig - Retrieving org list information from sfdx CLI.
I've removed the bin file from the settings and it now works. Don't know what happened...
That's odd. Does the project happen to contain an sfdx-project.json file? That's what IC uses to determine whether it's an SFDX project. Let me know if not and I'll need to research why it's doing this and fix it.
Nope - no sfdx-project.json file in this project.
Peter, traditionally in IC there are four ways to create a new project: 1) from scratch; 2) from an existing org; 3) from version control; 4) from the local filesystem. IC+DX doesn't yet support the first two well, but I'm planning to fix that in upcoming builds.
Soon you'll be able to create a new SFDX project locally (using force:project:create under the hood) along with a new scratch org in which to work (using force:org:create under the hood). You'll then be able to optionally retrieve metadata from an MDAPI org and have IC convert that metadata for use with SFDX, then push it into the scratch org.
Hope that answers your question!
Luke, okay, let me see if I can figure out why it's deciding to run force:org:list in that project. I might need you to gather some debug logs for me, but I'll dig in a bit first.
Scott, I experienced the similar issue as Luke at this comment above: https://bitbucket.org/RoseSilverSoftware/illuminatedcloud/issues/554/salesforce-dx-support#comment-38464584 .
There is no sfdx-project.json file in this project as it was created new from a traditional/MDAPI connection with the sfdx binary path populated.
IC downloaded temp metadata in the projectRoot/unpackaged directory.
I have also sent you the idea.log at the same time I posted the above commend.
IC worked normal after I removed the sfdx binary path in IC setting.
Thank you, Scott, for your explanation of the IC+DX's plan to support more ways to create a new project!
FYI, it looks like the most recent update to the sfdx CLI may have changed the JSON interface for a few commands including force:source:push. I'll try to get everything updated very shortly, but until I do IC may not work with the newer CLI.
Interestingly I just saw the same behavior that others have reported where it's treating a non-SFDX project as if it were an SFDX project. So the good news is that I've reproduced it (or I should say that it reproduced on my machine as I didn't do anything special). Should be easy to diagnose and fix at this point. I'll see if I can get a new build posted with this and fixes for the newer CLI version very soon.
Just a quick update. It appears that these issues are likely caused by the CLI updating to 40.2.0. It's actually done that on one of my machines, but my main IC dev machine is still on 40.1.1 which does not exhibit this behavior. I'm currently trying to force my install to the latest version (sfdx update doesn't seem to do it) so I can debug and fix these issues.
Peter and Luke, since you're both seeing these issues, can you run sfdx plugins and let me know the reported version number to see if it supports this assertion?
PS C:\ic> sfdx version
sfdx-cli/5.7.6-d42cf65 (windows-amd64) go1.7.5 sfdxstable
PS C:\ic> sfdx plugins
salesforcedx 40.2.1
Scott,
Have you tried sfdx plugins:install salesforcedx ?
While we were in SFDX Beta-prerelease, it seemed that sfdx update would remember the @prerelease if this command sfdx plugins:install salesforcedx@prerelease was run previously . And I had to run sfdx plugins:install salesforcedx to switch the @prerelease to the Official Beta Release.
Will reinstalling SFDX CLI 5.7.6 from the download link below help? (You might want to follow the SFDX Setup Guide to uninstall it first.)
https://developer.salesforce.com/media/salesforce-cli/manifest.json
https://developer.salesforce.com/media/salesforce-cli/sfdx-v5.7.6-d42cf65-windows-amd64.tar.xz
{
"released_at": "2017-06-19T17:48:22Z",
"version": "5.7.6-d42cf65",
"channel": "sfdxstable",
"builds": {
"darwin-amd64": {
"url": "https://developer.salesforce.com/media/salesforce-cli/sfdx-v5.7.6-d42cf65-darwin-amd64.tar.xz",
"sha256": "7c2056312b939b1e36cc65ad57d7d996865561f3cbe67e3557eed5aabee91e35",
"bytes": 12096588
},
"windows-386": {
"url": "https://developer.salesforce.com/media/salesforce-cli/sfdx-v5.7.6-d42cf65-windows-386.tar.xz",
"sha256": "ac4f080f7046a58160d53d27eccb20428e291fcc97b25e2370460f83d48904b4",
"bytes": 9616140
},
"windows-amd64": {
"url": "https://developer.salesforce.com/media/salesforce-cli/sfdx-v5.7.6-d42cf65-windows-amd64.tar.xz",
"sha256": "c69de24c32e253c5c1b0464c90f0f21a2c43ee6b58d013e4c891a145231c925b",
"bytes": 10769304
}
}
}
Thanks, Peter. Yes, I was able to force it to update that way yesterday afternoon. There is some bug in there that I've reported to Salesforce because sfdx update would not do it when it should.
I've diagnosed the issue that was originally reported and fixed it locally as well as updated to accommodate for the JSON changes in 40.2.1. I'll be posting a new build very shortly for you all to help confirm these fixes. Thanks for providing all the info to help debug this stuff!
Actually, I take part of that back...the new issue that results in "The directory does not contain a valid Salesforce DX project" is coming from the updated CLI, not from anything I've done. In my opinion it should be 100% valid to run sfdx force:org:list from any directory since that's based on info in the user home directory, not based on the working directory. I'm going to report this to Salesforce, but for the moment I'm not sure there's anything I can do to work around it since I don't know conclusively which directories in the local file system are valid SFDX projects. More to come on that one...
Okay, I just heard from Salesforce that the "The directory does not contain a valid Salesforce DX project" is a known regression and will be addressed in tomorrow's update to the CLI. That update will also fix the issue where the access token can go stale. I'll post the plugin update that addresses the changes in push/pull and tomorrow's CLI update should address the rest.
Thank you so much, Scott! :)
Okay, here's a build that addresses the push/pull incompatibilities. It does not address the problem in non-SFDX projects. That will be addressed by tomorrow's CLI update. If you're working in non-SFDX projects before the CLI is updated, you might need to move back to the official release temporarily.
Please let me know if this doesn't allow you to use push/pull on 40.2.1+, though.
"you might need to move back to the official release temporarily"
Or just remove the bin file from settings. That also works.
Thanks Scott. :)
Yes, removing the bin file path from the settings works for me too.
Thanks Scott and Luke! :)
By the way, the DX plugin version is still 40.2.1.
Luke, thanks for pointing out the simpler workaround for now!
Yes, I noticed that it hasn't been updated yet as well. I was told by the folks at Salesforce that it would be updated today, just not sure of their release timing. I'll try to keep an eye out for it and post here when it's updated and I've verified whether it does or does not resolve this issue.
I've got 40.3.0.
sfdx force:org:list --all not in a DX org directory generated error in 40.2.1. Now it comes back to normal.
Thanks, Peter! I've been indisposed much of today and unable to keep my finger on the pulse of things. Glad to hear that the update resolves the issue. For those of you trying out the pre-release build, please make sure that you're on the latest build of SFDX and the build posted here for the best results, and if you do see issues, please let me know about them here so that I can address them.
Hi Scott, let me start that I am really excited about SFDX and the work you do with IC to support, so thanks a lot for that!
I installed the last beta attachment and set the executable in the settings. The plugin was able to find my scratch org connects, so it seems to be working alright. However, when I opened a new project that I had just initialized with sfdx force:project:create ..., IC does not seem to pick that it deals with an SFDX project as I don't get any of the errors during start up as shown in your phase 1 demo video. I tried adding the scratch org connection manually, but it would never accept any connection, hence allowing me to generate the offline symbol table.
Is there anything that I missed in my steps?
I tried completely to remove the plugin and re-install it without success, either. Any help or pointer would be greatly appreciated.
I am using windows with the latest version of IDEA and the latest plugin version 40.3.0.
Thanks and have a great weekend, Johannes
I eventually figured out the issue. Apparently, IC did not detect the SFDX project because there was no source file in. Once I added an Apex class, removed the .idea folder and re-opened the folder in IC, I got all the messages to resolve the project errors.
Is this by design and if so, could you explain to us why a source file needs to be in there? Otherwise, it would be great if IC would detect even an empty project stub that was freshly created and does not have any files in it yet.
Thanks!
Hey, Johannes. Sorry for the delayed follow-up. Yes, right now the logic that determines if the contents of the filesystem represent an IC module looks for Salesforce-specific source. I haven't yet updated it to look for SFDX-specific stuff for a fresh project, in particular sfdx-project.json. That would have done the job for you. I'll include that in the next build so that you don't have this issue going forward. Thanks for reporting!
Hi Folks, I currently have a registered copy of IC, however when I uninstall that, and try an install the beta for DX, it disables itself. Anyone come across this? I'm seeing the following in the logs:
*2017-08-03 17:34:53,011 [ 40600] INFO - ellij.license.LicenseValidator - Initializing Illuminated Cloud 1.7.9.7 (20170726125927). at com.illuminatedcloud.intellij.license.LicenseValidator.<clinit>(SourceFile:71) at com.illuminatedcloud.intellij.license.ValidateLicense$1$1.run(SourceFile:28) at com.illuminatedcloud.intellij.license.ValidateLicense$1.run(SourceFile:23) at com.illuminatedcloud.intellij.license.ValidateLicense.runActivity(SourceFile:18) 2017-08-03 17:35:08,376 [ 3201] INFO - llij.ide.plugins.PluginManager - Plugin 'Illuminated Cloud' can't be loaded because: Plugin is disabled *
Rowan, you're correct that it should just work with your existing license key. How are you installing the test build of the plugin? Do you mind emailing me your full idea.log?
Hi Scott, thanks for the quick response :-) However, I've discovered that I'm an idiot. I extracted the zip file and selected IlluminatedCloud.jar when installing the component from disk, instead of selecting the entire zip file. Everything works correctly now. Apologies, and thanks.
Now Salesforce DX plugin is 40.5.0.
sfdx plugins:install salesforcedx@latest
(or sfdx update)
sfdx plugins
salesforcedx 40.5.0
Salesforce DX will be GA in Winter '18 based on the Salesforce DX Intro webinar on August 10.
New test build that catches it up with the official 1.7.9.9 release. No new SFDX-specific changes here. A new SFDX feature build will be coming in the next week or two.
Does SOQL execution us SFDX or the old APIs?
Are all the old features relying on SFDX or is it a mixture at this point?
Only login, push, and pull explicitly use the SFDX CLI. All other operations that interact with the org use the same mechanisms as IC against a traditional org. It will likely stay that way for the most part because I'm able to provide a much more sophisticated feedback to the user regarding progress of long-running operations, etc., than is possible with the CLI right now. Is there a particular reason for the question?
No, mostly just curious. I was running some SOQL yesterday to figure out why my Lightning component was displaying any data. My normal workflow has me using the CLI in an Intellij terminal window.
Gotcha. I thought perhaps you were asking whether IC would support SOQL queries to the Tooling API now, and unfortunately it still doesn't. I do want to support that, but I don't quite yet.
OK. I ran the queries from the SOQL tab at the bottom of the screen. Worked fine. I'm happy.
I've come across a strange issue. I have multiple modules in my project (each from separate repositories), for simplicity called module 1 and module 2 each pointing to the same DX scratch org. However if I make a change in module 2, right click on it, and click Push Metadata a message appears Push Complete - All files are up-to-date. The problem is that it seems to always try and push module 1 regardless of the context that I'm in. Has anyone else encountered this?
What happens if you try to push from a terminal command line?
Pushing from the terminal command line works perfectly. It just had me stumped for a while when I was using the IDE
Just a small, potential bug:
When pulling data from scratch org, the event notification says "Push Complete" instead of "Pull Complete"
Thanks, Kamil! I'll make sure that's fixed in the next SFDX build.
Kamil, I'm unable to reproduce the message you cited above. I'm seeing "Push Complete" after doing a push and "Pull Complete" after doing a pull.
I can still see it every time I do pull. I am running the latest version of Intellij and Illuminated Cloud Version: 1.7.9.9-idea14
Also, event log doesn't give me as detailed feedback as using the force:source:push/pull commnd in the console would. All I see is status 0 or 1.
I've also been getting this. Everything I do is referred to as a push.
Ah, I see it. I'm going to be posting a new build this morning. I'll fix that real quick before doing so. Sorry I missed it the first time around!
Another new build that catches the SFDX build up with 1.8.0.1 and 1.8.0.2.
It also adds an SFDX-specific tab to application configuration where the path to the executable is configured plus a few new options for deciding when an automatic push to the server should take place. Note that these options are all disabled by default which is a change in default behavior from previous builds. Feel free to enable whichever best suit your particular workflow.
This may be the last test build as I'm planning to fold this into the official build very soon. I'm in the process of adding the SFDX new project wizard and integrated scratch org management now.
This is just a minor update to pull in the fix for issue #709. If you don't use tabs for your indents, no need to update.
I can't change subscription to i.e. pull custom object metadata.
That's correct, Stefan. In a Salesforce DX project, there is no explicit subscription management. Salesforce DX is responsible for determining what metadata should be moved back and forth between the filesystem and the scratch organization. There have been discussions with the SFDX team about allowing more selective subscriptions and subsets during push/pull, but those features aren't available yet.
If you're seeing an issue where you've added something in the organization and a pull isn't bringing it down into the filesystem, let me know. If you can reproduce the behavior when doing a direct sfdx force:source:pull from the CLI, it's an SFDX issue that should be reported to that team ASAP. If you can't reproduce it outside of IC then it's something I'll need to debug and fix.
I'll move around a bit and then let you know. Thanks Scott.
FYI, I've implemented the SFDX new project wizard and integrated scratch org management so I will be prepping this feature for official release this week. I can post a new pre-release build here as I do so if anyone wants to help burn in these new features.
Hi Scott, I’d love to give it a go.
Sounds good. I'll try to post a new build here tonight along with a short video showing the new features. I want to do a solid round of testing of the build against SFDX and non-SFDX configs -- in particular to make sure I haven't broken the latter accidentally -- before releasing this as the new official build. I'll post a comment here when the new build is available.
I'm also intrested.
Okay, here's the new build, and here's a short(-ish) video showing the new features:
Note that YouTube is still transcoding the video for various resolutions so the quality is still pretty poor; you might give it an hour or so before watching it.
As always, let me know if you find any issues. As I stated above, and as noted at the end of the video, I plan to make this the official release in the next few days.
There was a small bug in the build I uploaded this morning if you don't have the SFDX binary configured. This fixes that issue. Please update to this one if you grabbed the first one this morning.
Hi Scott, Great new features! Is it possible to add the same feedback level to Push and Pull commands as it is when they are run in the terminal? And add sfdx force:source:status command to Illuminated Cloud drop-down and/or toolbar?
Kamil, by feedback do you mean the details about which files were created/updated/deleted at the end? If so, it does output that information into the Messages view:
As for force:source:status, yes, I'm definitely planning to integrate that in a first-class manner and annotate the local source files according to the results. I actually have a pretty long backlog of SFDX features that I want to implement, but I think the current feature set should provide a pretty solid initial implementation.
Whoops, I missed messages window - yes this is what I was after.
FYI, I'm hoping to release this (along with a few fixes) in the official build tomorrow. When I do so I'll resolve this enhancement and let those of you using the test build know that it's safe to get back onto the official build. I sincerely appreciate you taking the time to help burn in the test build and providing feedback along the way. While this release does represent the first official set of Salesforce DX features, there will of course be more enhancements to the IC/SFDX integration in the relatively near future. More to come tomorrow!
So tomorrow it will be availiable as the official IC version without needing to download the extension manually?
Javier, I actually have it ready to go now. I just need to find a spare hour to go through the release steps. Hopefully I'll have it posted to the official plugin repo in a bit. But yes, once I do so...today or tomorrow morning...you won't need to download a test build from here anymore.
Man, Scott, you're the best. I think IC has probably one of the best purchases I've made in the last couple of years. Keep the good work up and thanks for everything you do for us! 
You bet, Javier! Glad to hear.
Okay, at this point I'm going to wait to release until tomorrow morning. I really prefer to release in my morning so that if problems are encountered by users taking the update I have my full day ahead of me to field them. Look for it first thing tomorrow morning!
As of 1.8.0.4, Salesforce DX is now part of the released product. Feel free to update using IntelliJ's internal plugin management mechanisms for the latest-and-greatest.
So cool. Thanks Scott!
Just watched your Youtube video's as well; I'm looking forward to using this as soon as I can!
Here's a pre-release/test build with Salesforce DX support. It can be installed by using Settings>Plugins>Install plugin from disk against the attached archive. Please watch this video for an overview of the currently supported features. Note that right now IC's metadata retrieve operation still works against a single source root. I'll be addressing that in a subsequent build.