Only DX connections visible if sfdx-project-json present

Issue #1570 resolved
Reede Stockton created an issue

I’ve categorized this as a bug, but I’m not entirely sure that is justified. I does seem to be a recent behavior change.

The presence of sfdx-project.json in the project root directory when a project is opened appears to determine the type of connections available to be selected as the configured connection for the module. That’s a bit of a pain since sfdx-project.json is always a part of the repo we use. Connections available in the ‘Open Connection’ dropdown are unaffected.

This is a fairly easy issue to work around, since all I need to do is temporarily rename sfdx-project.json and re-open the project to get around the issue, so I’m not sure it is worth the effort to address. Still, I thought it might be useful to note that it is an incorrect assumption that all projects with sfdx-project.json in the root directory only want to have dx connections available for module configuration.

Thanks!

Comments (3)

  1. Scott Wells repo owner

    Reede, the issue is that IC uses the presence or absence of sfdx-project.json to determine whether the associated metadata should be interpreted as source format or metadata format respectively. If the former, native IC connections are not allowed with that project because IC is not directly responsible for the deployment or retrieval of source format metadata; it uses the CLI for those purposes (with the exception of direct API-based deployment of things supported by the Tooling API for efficiency). If the latter, both native IC connections and CLI-based OAuth connections can be used with the project.

    Without doing some type of deeper inspection of the local source--which could be wrong if the only metadata stored locally doesn't vary between source format and metadata format, e.g., Apex source files--or requiring the user to specify explicitly how the project should be interpreted, it's critical that IC have some deterministic way to discern the project format to drive other decisions.

  2. Reede Stockton reporter

    That seems entirely reasonable, and as I mentioned, it is a minor annoyance at best. What’s weird is that since working with this repo, my standard practice has been to clone our repo, then begin working with IC in metadata format by opening the directory with IntelliJ. The appropriate connections have been available to me in the past and everything just worked, without me doing anything special.

    In any case, I don’t think it’s worth spending time on, and it does seem completely appropriate to rely on something non-intrusive (like the presence of sfdx-project.json) to make the decision about what type of project the current project is.

    I wonder if the reason my workflow used to work is because I opened a directory rather than creating a project from scratch? Something is sending things down a different path now…

    Anyway, feel free to move on to more important stuff. I’m not even sure this rises to the level of “trivial”.

    Thanks!

  3. Scott Wells repo owner

    I'm not sure what would have changed that might lead to the behavioral change you're noticing. Unless it's a result of me tightening up some of IC's project structure detection logic to find sfdx-project.json files even if they're not at the top and infer project/module structure in a more robust fashion.

    As you mentioned, I'm going to resolve this for now because that file is a critical part of how IC discerns the type of project that it sees and therefore which functionality should be applied.

  4. Log in to comment