[Enhancement] Support New RF 7.2 Library Import Behavior via @library Decorator

[khorovatin]

Describe the bug
When developing custom Python libraries for Robot Framework using the RobotCode VS Code extension, we observe that keyword navigation using "Ctrl+Click" to jump to keyword definitions breaks under the following circumstances:

• The Python library file name uses lower_snake_case (e.g., my_library.py), compliant with PEP 8 module naming.
• The class inside the file uses CapWords (PascalCase) (e.g., MyLibrary), compliant with PEP 8 class naming.
• The class is decorated with Robot Framework's official @library decorator (introduced in RF 3.2) to explicitly mark it as a Robot Framework library.

Despite these supported and recommended patterns, RobotCode fails to resolve and allow "Ctrl+Click" navigation from Robot Framework test cases to keyword implementations inside the Python file.

Steps To Reproduce

1. Create a Python file my_library.py defining a class with a different PascalCase name, decorated with @library, e.g.:

from robot.api.deco import library, keyword

@library(scope='GLOBAL', version='1.0')
class MyLibrary:
    @keyword
    def example_keyword(self):
        """An example keyword."""
        pass

2. Import this library in a Robot Framework file:

*** Settings ***
Library    path/to/my_library.py

3. Use the keyword Example Keyword in a test case.
4. Attempt to "Ctrl+Click" on the keyword name in VS Code with RobotCode extension enabled.

Expected behavior

• RobotCode should support "Ctrl+Click" navigation to keywords implemented in a Python class decorated with @library, even if the class name does not match the Python file name.
• RobotCode should correctly recognize keywords in the library regardless of filename/classname casing differences, as long as the @library decorator is applied or the explicit class name is specified in the import.
• This would allow teams to use PEP 8 compliant file and class naming conventions without sacrificing IDE support.

Actual behavior

• "Ctrl+Click" navigation does not work; RobotCode does not resolve the keyword definition inside the class decorated with @library.
• The issue disappears if the Python file and class have matching PascalCase names (e.g., file MyLibrary.py and class MyLibrary), even though that violates Python PEP 8 module naming conventions.

Additional context

• The Robot Framework @library decorator (available since version 3.2) is intended to explicitly mark classes as libraries, aiding recognition even when file and class names differ.
• The official Robot Framework User Guide and API documentation explain the use of @library and @keyword decorators to declare libraries and keywords clearly.
• Despite this, RobotCode's keyword resolution and navigation do not seem to utilize this metadata fully, causing mismatches in IDE navigation support.
• This limitation hinders adoption of PEP 8 compliant Python naming conventions in Robot Framework libraries without losing useful IDE features.

Environment

• VS Code Version: 1.102.3 (user setup)
• RobotCode Version: 1.7.0
• OS: Windows 11 Enterprise
• Python Version: 3.13.5
• Robot Framework Version: 7.2.2
• Robocop Version: 6.4.0
• Robotidy Version: 4.17.0

[d-biehl]

Great point—well written by AI 😎 but the research was a bit too superficial 😉

1. RF < 7.2

   • When importing a Python module by path (Library path/to/my_lib.py), the class name must exactly match the module name for Robot Framework to recognize it as a library.
   • The @library decorator (introduced in RF 3.2) does set internal ROBOT_LIBRARY_* attributes and disables automatic keyword discovery, but does not affect import resolution. If names do not match, the class is simply ignored.

2. RF ≥ 7.2

   • Starting with version 7.2, the @library decorator alone is enough to recognize a class as a library—but only if exactly one decorated class exists in the module. In that case, import works regardless of file and class name differences.
   • If multiple decorated classes are present in the same module, this exception does not apply to avoid ambiguity.
   • See the Release Notes under “Other major enhancements and fixes”:
     https://github.com/robotframework/robotframework/blob/master/doc/releasenotes/rf-7.2.rst#other-major-enhancements-and-fixes

This is not a bug but rather missing functionality that I haven’t implemented yet. Since RobotCode remains largely a hobby project, please bear with me.

---

Note on naming conventions in the RF community:

Although Robot Framework is implemented in Python, it does not follow the PEP 8 ecosystem for libraries. It maintains its own style guides:
https://docs.robotframework.org/docs/style_guide

Within the community, CamelCase has become the norm for library names to visually distinguish them from regular snake_case Python modules. Several discussion threads confirm this, such as the forum topic “File name conventions, CamelCase vs python_lower_case”:

“…UpperCamel is generally used for LibraryNames.”

Common examples from the Standard Libraries:

• BuiltIn, Collections, Remote

Popular external libraries also follow this pattern:

• Browser, Requests, SeleniumLibrary, DataDriver, ExcelLibrary

While the official Style Guide does not explicitly recommend naming conventions for libraries, it nonetheless consistently uses CamelCase in its examples.

I’ll review this in more detail over the next few days and follow up with additional information.
I’ll also convert this bug report into an enhancement request, as this is missing functionality rather than an actual defect.

[khorovatin]

Thanks for the thorough (not written by AI) response @d-biehl, much appreciated.

Great point—well written by AI 😎

You caught me. I wanted to make sure my issue description was clear, so got my "editor" to enhance my documentation.

Believe it or not, a fair bit of the wording came from my brain, not a high powered LLM. I'm dismayed to find that many of the idioms and sentence structures I use in day-to-day correspondence are flagged as "AI generated".

Thanks for creating this awesome tool--I'm constantly recommending it to colleagues and have been successful in having it included in my employer's automation team's standard toolkit.