IC2 removing .resource file type association on every startup

[Kris Goncalves]

We leverage Robot Framework in our repo with our salesforce package - so there's files with .resource file type - I am unable to actually diff files/associate them to the robot framework plugin because it seems IC2 is overwriting the association? 

Is there a way to exclude them from being overwritten by IC2? Or am I wrong in the root cause here - I have no issue in VS Code diffing/using robot files.

This is the log line I see in idea.log

> 2026-03-02 11:36:29,996 [ 12066] INFO - #com.illuminatedcloud.intellij.common.fileType.IlluminatedCloudFileTypeRegistry - Removing file type association for resource.

[Scott Wells]

Hi. No, you’re correct that IC is doing that. It’s in support for *.resource files in metadata format projects and allows IC to determine the actual file type for those files dynamically at runtime based the <contentType> value in the associated *.resource-meta.xml file. That way the static resource is opened in the correct editor, etc., even though the file extension doesn’t provide any insight into the actual file type. IC does similar for other ambiguous file types such as documents, content assets, and email templates.

Of course, that’s not necessary in source format projects where those files are named with the correct extensions on disk, and it sounds like for you this is causing an issue because you have another registation for that extension.

I can certainly allow you to disable the dynamic file type discovery logic if you’re definitely never going to be using metadata format projects. Would you mind logging a bug in the public issue tracker for that so that it’s concretely on my radar?

Regards,
Scott Wells

​

[Kris Goncalves]

I updated to the latest today - but, I'm still seeing this in the log - 

2026-03-05 12:48:03,586  INFO - IlluminatedCloudFileTypeRegistry -

  Removing file type association for resource.

  2026-03-05 12:48:03,615  INFO - FileTypeManagerImpl - File types
  changed: file type
    'com.github.jnhyperion.hyperrobotframeworkplugin.psi.RobotResourceFile
  Type@61627fa5'
    association with '*.resource' has been removed. Caused by plugin
  'com.illuminatedcloud2.intellij'.
      at IlluminatedCloudFileTypeRegistry.lambda$unregisterDetectedFileTyp
  es$5(SourceFile:238)
      at IlluminatedCloudFileTypeRegistry.lambda$unregisterDetectedFileTyp
  es$6(SourceFile:238)

Not sure if it's checking anything specific in the project to determine source format vs. not (something my local project might be adding confusion too - we do have unpackaged directories with package.xml files). Or if there's anything I could give you to get more info. We do have the .resource files not within the force-app directory. 

I can get it to work, for the current session, through file --> file properties --> associate file by type. But, it gets wiped out every restart.

[Scott Wells]

Okay. Sorry about that. Can you please explain the project structure, specifically where this file is found relative to the project root directory, whether that's under a configured source root, and whether there's an sfdx-project.json file immediately under the project root directory? Those are some of the things IC is looking for to determine whether or not to process a given file for a dynamic file type.

Regards,

Scott Wells

[Kris Goncalves]

No worries - I know this is a niche use-case so appreciate the look here

- sfdx-project.json is immediately under the project root.
- Two package directories (source roots) are configured: force-app (default) and custom-metadata.
- The .resource files are under the project root in robot/automation/tests/. They live completely outside the configured Salesforce source roots.

root/                                  ← project root
  ├── sfdx-project.json                   
  │
  ├── force-app/                           ← source root #1 (default)
  │   └── main/default/
  │
  ├── custom-metadata/                     ← source root #2
  │   └── ...
  │
  └── robot/                               
      └── automation/
          └── tests/
              └── UI/
                  ├── someDomain/
                  │   └── resources/
                  │       └── license.resource       ← Robot Framework resource

[Scott Wells]

Kris, do you think you could put together a very simple, standalone source format project that reproduces this behavior for you? I’m just not seeing, and I’m sure it’s because I think I’m modeling exactly what you have, but I’m not. It should hopefully be as simple as a mostly empty source format project with an sfdx-project.json file in the root, a dummy Apex class under force-app/main/default, and a stub license.resource file under robot/automation/....

Apologies for having to ask you to do that, but I think that will help me reproduce and fix the behavior properly quickest.

Regards,
Scott Wells

​

[Kris Goncalves]

So it seems it only happens as soon as I add an unpackaged directory (under root) which contains a package.xml (which we do have!) So probably confusing the situation