Configuring VS Code Robot Framework Extension to Resolve Imports from a Central Resource File

[naveen-pt]

I have structured my Robot Framework project such that all libraries and shared resources are imported in a single file (common.resource), and this file is then imported in individual test case files. I have not imported libraries in the individual keyword resource files to avoid redundancy, as they are already included in common.resource. While this setup executes without issues, my IDE (VS Code extension) shows errors in the individual keyword resource files because it doesn't recognize the libraries and resources declared in common.resource. Explicitly importing common.resource in each keyword file creates circular import warnings, which I want to avoid. Is there a way to configure the extension to prioritize resolving imports from common.resource automatically for all files?

[d-biehl]

No, unfortunately, there isn’t a way to configure the RobotCode extension to automatically resolve imports from a central common.resource file for all files. To be honest, the way you’re currently structuring your project isn’t considered good practice either. Centralizing all libraries and resources in a single common.resource file and importing it into all test cases and keyword resource files leads to several issues:

1. Circular Imports: If common.resource is imported into keyword resource files, circular dependencies can occur because this file is often already included in other files. This can result in warnings or unexpected behavior.

2. Risk of Overwriting Keywords or Variables: A central common.resource file increases the chance of unintentional overwriting of keywords or variables with identical names. This can cause hard-to-debug issues and unexpected behavior during test execution.

3. Performance Issues: Robot Framework checks all known keywords and variables during execution to resolve calls and avoid collisions. A centralized file with many unused keywords and variables significantly increases processing time, especially in large projects.

4. Increased Complexity for Users: A single file containing hundreds or thousands of keywords makes it harder for users to find the relevant ones while writing test cases. This reduces productivity and complicates the test creation process.

---

Solutions:

1. Modularize Your Resources:
   Define a common.resource file that only includes the libraries and resources genuinely required by all test cases and keyword files. For everything else, import only what’s needed in your tests or resource files.

   • You can group similar resources into their own files, e.g., business-specific (functional) keywords and technical keywords.
   • This structure avoids circular imports entirely and maintains modularity.

2. Disable Warnings in RobotCode:
   If you prefer to stick with your current solution, you can suppress warnings about circular imports and already-imported resources in RobotCode. Here’s how:

   • Directly in the Files:

     # robotcode: ignore[*ResourceAlreadyImported*, PossibleCircularImport]
     *** Settings ***
     Variables  variables
     
     Resource  already_imported.resource  # robotcode: ignore[ResourceAlreadyImported]
     Resource  circular_import.resource  # robotcode: ignore[PossibleCircularImport]

     • The first line disables all relevant warnings for the entire file.
     • Alternatively, you can disable specific warnings directly next to the problematic lines.

   • Globally in the Project:
     In VS Code settings, you can disable these warnings globally for your project. Search for robotcode.analysis.diagnosticModifiers.ignore and add the relevant codes (ResourceAlreadyImported, PossibleCircularImport) to the list.

---

Conclusion:

It’s best to adopt a modular resource structure and only import what’s truly needed to avoid performance and maintainability issues. However, if you want to stick to your centralized solution, you can suppress RobotCode warnings either in specific files or globally for the project.

For more details on this topic and potential issues with centralized common.resource files, check out this YouTube video, which explains the challenges and solutions in greater depth.

[gohierf]

This definitely needs to be copied to the documentation, if it is not already planned to do so!

[d-biehl]

@gohierf Do you have a suggestion as to where this should go in the documentation? And do you perhaps have the time and leisure to write it so that it can be included in the documentation?

[gohierf]

I was going to suggest to put that in a FAQ section. But then I see that robotcode.io already has a shortcut toward this Q&A.

Yet, I am not sure that this is the most likely place people will look for this kind of information.

Maybe a "Why a central resource file project structure should be avoided?" section in Tips and Tricks would be more likely to be found?

What do you think @d-biehl ? I can try adding it to Tips and Tricks if you agree this is the right location.

[naveen-pt]

@d-biehl I understand that centralizing all libraries and resources in a single common.resource file and importing it into all test cases and keyword resource files might not align with best practices.
Here’s the issue I face:
When I work with individual keyword resource files (e.g., login.resource), which rely on dependencies declared in common.resource (like SeleniumLibrary), the IDE (RobotCode) doesn’t recognize those dependencies, leading to “keyword not found” errors. Explicitly importing common.resource into each keyword resource file resolves the IDE errors but introduces circular import warnings.

Is there an IDE-level workaround to let RobotCode infer dependencies from common.resource for all files? For example, could a custom configuration be added to let the IDE resolve imports via common.resource without explicitly importing it into each resource file?

I’d prefer not to restructure the project if possible, as this setup works well during execution and is manageable for my project’s size.

Current Structure:
You’ve adopted the centralized common.resource approach to manage imports efficiently and avoid redundancy. For example:

All libraries (e.g., Selenium) and shared resources are managed in common.resource to avoid importing the same libraries repeatedly in each keyword file (like login.resource).
The keyword resource files (login.resource) only define modular, task-specific keywords and rely on common.resource for their dependencies.

Currently, my project structure doesn’t have any circular import problems because I include common.resource only in the test case files, not in the individual keyword resource files (e.g., login.resource). The keyword resource files rely on the libraries and variables declared in common.resource via the test cases, which avoids any circular dependencies.