Creating a new SFDX project creates the wrong project type

Issue #2410 resolved
Aidan Harding created an issue

This one seems like such a stopper that it must be depending on something weird in my setup. But maybe you can guide me with what extra information you need to figure out what that is.

I create a new project using File->New->Project… and then pick Illuminated Cloud SFDX. IC prompts me with the Module Config dialog, and I click on the + to create a new scratch org. Then I click the DX icon to make a new scratch org.

This creates a scratch org, and pre-selects it in the connections config dialog. Then, when I click OK to get back to the module config, I get this:

And then the Module Config only lists org connections, not SFDX connections.

I end up working around it by creating a .idea/illuminatedCloud.xml file with the connection type set in it i.e. <option name="connectionType" value="SFDX" />. Once I’ve done that, IC recognises that I wanted SFDX and lets me pick the scratch org in the module dialog. But something is going wrong in the project-creation process.

Comments (9)

  1. Scott Wells repo owner

    Well, this week’s build did remove the IC-specific module type, so it’s very possible that you’ve found an issue that I didn’t find during my testing. It sounds like you just went through the standard process for creating a new project, correct? And is this in IntelliJ IDEA or in one of the lightweight IDEs such as WebStorm? The new project wizards are actually different between the two.

    There’s one other possibility…I’ve found an intermittent--though thankfully quite rare in my experience--issue where immediately after creation of an SFDX project, the IDE’s virtual file system doesn’t yet “see” the sfdx-project.json file due to stale caching and IC2 therefore thinks the project is a metadata format project. In that situation, you can cancel the “fix the module” stuff, close and reopen the newly-created project, and things work properly. It’s obviously less than ideal, but I haven’t yet figured out how to force the cache to update in a way that fully eliminates that behavior.

    Let me know and I’ll take a look.

  2. Aidan Harding reporter

    This has been happening for some time (a few months). I just hadn’t got around to reporting it because I tend to start by checking a project out from git these days and there’s no problem there. So I don’t think that it will be related to recent changes.

    Thanks for the tip on the virtual file system. I got into the same situation, closed the project and re-opened. It did then let me pick the SFDX connection. Weirdly, I could see the sfdx-project.json at the same time as the error:

    That is a much better workaround than what I had, though, so thanks!

    As far as I know, this was the standard project creation method but there are always multiple ways in IntelliJ, so wanted to list it all out. I’m specifically using:

    WebStorm 2023.2
    Build #WS-232.8660.143, built on July 21, 2023
    Runtime version: 17.0.7+7-b1000.6 aarch64
    VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o.
    macOS 13.4.1
    GC: G1 Young Generation, G1 Old Generation
    Memory: 5000M
    Cores: 8
    Metal Rendering is ON
    Registry:
        debugger.new.tool.window.layout=true
        ide.experimental.ui=true
    
    Non-Bundled Plugins:
        com.intellij.ideolog (222.1.0.0)
        Statistic (4.2.7)
        com.github.copilot (1.2.18.2908)
        com.illuminatedcloud2.intellij (2.2.7.7)
    

  3. Scott Wells repo owner

    Okay. That makes me feel better about this week’s build as it sounds like it’s an instance of the caching issue that’s been around for a bit. And yes, it’s weird that you can see it in the project view but when IC2 asks the VFS for that file, it doesn’t seem to exist. I’ll tinker with it a bit more next week and see if I can find the way to sequence the VFS forced cache refresh and the check for that file to determine the project…minimally see if I can narrow the window of opportunity for this a bit. Since you’re obviously able to reproduce this quite reliably, I may post a test build here with…whatever I do…to see if you can help verify its effectiveness.

  4. Aidan Harding reporter

    Thanks, Scott. I’m happy to try a test build if/when you have one.

    It happens 100% of the time for me when I create a new SFDX project so it should be a good place to test.

  5. Scott Wells repo owner

    Okay, here's a test build with a prospective fix(/improvement). I was able to reproduce the behavior pretty consistently in WebStorm without this change, and with this change I don't see it at all. Of course, I don't know if perhaps the very act of trying to observe the change (debugger, logging, etc.) might be changing timing to avoid it vs. a real world scenario...the proverbial Heisenbug.

    If you get a free minute, do you mind installing this build to see if it makes a difference for you?

  6. Aidan Harding reporter

    Hi Scott,

    I tried the new build and it did fix the problem! I tried it immediately beforehand to make sure the problem was still there (it was). And again after installing your zip file. It worked perfectly on the new build.

  7. Scott Wells repo owner

    That’s great! Thanks for helping to confirm. Pending more thorough testing, that should be included in this week’s build.

  8. Log in to comment