Recognize source code outside of source roots and assist with proper configuration

[Cesar Parra]

Co-opting the original issue detailed below to provide better UX when source code is found in a project that is not under a (test) source root or an exclude root. This can lead to an unexpected lack of plugin functionality for that source code, and the fix isn't intuitively obvious, especially to those unfamiliar with the JetBrains IDE concepts of content roots and source roots.

When "unmanaged" source code/metadata is found--i.e., not under an explicit (test) source root or exclude root--IC should prompt the user to mark it as one or the other so that it's either properly treated as source or no longer included in this type of validation.

ORIGINAL ISSUE DETAILS

Reproduction:

Given a directory structure that looks as follows for an sfdx project:

• force-app

  • main

    • default

      • classes

        • SomeTestClass.cls

  • othermodule

    • classes

      • AnotherTestClass.cls

AnotherTestClass doesn't seem to be recognized as a valid test class.

The following behavior occurs on these tests:

1. Run → Run is not available to run the tests
2. Tests don’t appear in the Apex Unit Tests configuration
3. An inspection error shows up

‌

[Scott Wells]

Have you added othermodule as a source root, i.e., Right-click>Mark directory as>Sources Root? All directories which contain source must be marked as a source root or test source root for IC to treat them as project source.

[Cesar Parra]

@scott wells I had not, and that did it!

Is that a new requirement, I’ve had this structure for a while but hadn’t run into that issue before.

Anyways, thanks for the help! Let me know if you want me to close this as invalid.

[Scott Wells]

It's not a new requirement, no. IC has filtered for files under a registered source root since its initial release. Having said that, it's possible that this particular code path wasn't as restrictive before and some (relatively) recent refactoring made it more (and properly) restrictive.

Let's leave this open but I'll change the subject to reflect having IC look for situations where obvious source code is not marked as a source/test source root and also is not marked as excluded. That way it can at least help the user decide which it should be and mark it as such explicitly.

[Cesar Parra]

Got it.

For what is worth my first instinct was to make sure that all appropriate paths where referenced from the sfdx-project file, in case that was what IC was looking for when parsing the files.

[Scott Wells]

Yep, I definitely think that in situations where an sfdx-project.json is available, it should use that information. There are situations where this can happen outside of an SFDX/source format project, though, and it should assist in those situations as well. I've updated the subject and description accordingly. I'll take a look at this in the next few weeks. No doubt that it would be a very useful UX improvement, especially now that SFDX/source format projects allow so much more flexibility in metadata organization.

[Scott Wells]

IC2 does (or at least should) now properly warn the user when working with files that are under a package directory from sfdx-project.json but are not under a configured source root. I believe that addresses this request, no?