Summary

There is an inspection in place that reports the httpsPort attribute of the @WireMockTest annotation when httpsEnabled is false either explicitly or by default.

Tasks

• To speed up the addition, a quick fix should be created that either adds httpsEnabled = true if the attribute is not specified, or changes httpsEnabled = false to httpsEnabled = true if it is specified.
• The intention name could be: Enable HTTPS.

Summary

A stub mapping file may contain a single mapping like this:

{
   "request": { ... },
   "response" : { ... }
}

When users want to expand the mapping file to hold multiple mappings, they would probably edit the file manually and wrap the snippet in mappings like this:

{
  "mappings": [
    {
       "request": { ... },
       "response" : { ... }
    }
  ]
}

To make this easier, an intention action could be implemented.

This is essentially the opposite direction of #33.

Tasks

• Create an intention action that would wrap a single mapping with mappings.
• Users could invoke the action by placing the caret before/after opening { of the stub mapping.

Summary

There are a couple of builder classes in WireMock whose certain fields have default values.

Tasks

• Create an inspection that, where possible, would report calls to such builder methods with their default values.
• One such examples is WireMockExtension.options() with the WireMockConfiguration.wireMockConfig().dynamicPort(); default value.
• Other related classes:
  • com.github.tomakehurst.wiremock.matching.MultipartValuePatternBuilder
  • com.github.tomakehurst.wiremock.matching.RequestPatternBuilder
  • com.github.tomakehurst.wiremock.client.ResponseDefinitionBuilder
  • com.github.tomakehurst.wiremock.recording.RecordSpecBuilder
  • com.github.tomakehurst.wiremock.core.WireMockConfiguration
  • com.github.tomakehurst.wiremock.client.WireMockBuilder

Summary

There are a lot of features for stubbing in the Java DSL. Look into and add support for stubbing call chains via the WireMockServer/WireMockExtension class, esentially classes that implement com.github.tomakehurst.wiremock.junit.Stubbing.

Summary

To check the validity of json mapping files, WireMock schemas could be bound to them.

Tasks

• Implement the candidate JavaScript.JsonSchema.ProviderFactory extension point to provide the linked WireMock schemas to mapping files.
• If possible, restrict the application of the schemas only to json files in folders called mappings.

To be clarified

• Should the schemas be in yaml or json format?
• Investigate if schemas can be limited to certain files, more specifically json files in mappings folders.

Resources

• WireMock schemas
• Candidate extension point: JavaScript.JsonSchema.ProviderFactory
• Related classes:
  • com.jetbrains.jsonSchema.extension.JsonSchemaProviderFactory
  • com.jetbrains.jsonSchema.extension.JsonSchemaFileProvider
  • In other plugins
    • org.jetbrains.idea.devkit.themes.ThemeJsonSchemaProviderFactory in the devkit plugin
    • com.jetbrains.jsonSchema.extension.JsonSchemaProjectSelfProviderFactory in the json plugin
• https://intellij-support.jetbrains.com/hc/en-us/community/posts/360003238559-JavaScript-JsonSchema-ProviderFactory-extension-overrides-other-completion-contributions

Summary

There are some helper specific checks that could be added to the Handlebars helper inspections.

Tasks

• pickRandom doesn't make sense if there is only one literal specified.
• The padding hash of base64 is applicable only during encoding.
• In case of math, if there are exactly 3 parameters specified, the middle one being a string literal, validate if it is one of the supported operations

Summary

There is support for indexed path segments in URL path templates since wiremock/wiremock@25b82f9.

Investigate and implement/update features to support the indexed variables.

Questions

• What if the indexed variables' indeces don't start at 0?
  • Not a problem.
• What if indexed and named variables are in a mixed manner?
  • Indexed variables seem to be prioritized over named ones.

Summary

WireMock 3.0.0-beta-8 is out. Make sure to cover its features.

Tasks

• Include schema matcher in json-to-java conversion.
• Validate default json schema version value on at least java side.

Resources

• Release notes: https://github.com/wiremock/wiremock/releases/tag/3.0.0-beta-8
• JSON schema matcher: wiremock/wiremock@bb62fc9
• Filename template support: wiremock/wiremock@d721662

Summary

With the introduction of request.urlPathTemplate and request.pathParameters properties in WireMock 3.0.0-beta3, the need has arisen to provide different stub-mapping JSON schemas based on the version of WireMock used in a project.

Tasks

• Detect and cache the used WireMock lib version at project launch for each module in the project.
• Listen to classpath/dependency changes in each module, and update the cached WireMock version.
• Implement a logic that provides different schema files based on the cached WireMock version.

Summary

Create action to generate mapping file with pre-defined and potentially customizable settings.

Tasks

• Create an action that is available only on directories named mappings.
• The action would bring up a dialog with these options: generate for single mapping, generate for multiple mappings
• Make sure the default focus is on the OK (or similar) button, so that when no modification is done, users can go with the defaults with a single Enter.

To be clarified

• Look into DialogWrapper and similar dialog implementations.
• Find a suitable icon for the action.
• Clarify whether a radio button group with two buttons, or a single checkbox to enable/disable multiple mappings is more suitable.

Summary

WireMock has its custom helpers for Handlebars: https://wiremock.org/docs/response-templating/

Tasks

• Create an inspection that can perform validation on WireMock's custom helpers:
  • if the number of params are not within the range of required minimum and allowed maximum numbers
  • the same number for the case when a helper is used as a block helper
  • whether a helper can be used as a block helper
  • whether required hashes are not specified in a mustache
  • custom validation on hash values and other more complex items

To be clarified

• Should each helper have an option to enable/disable them separately?

Summary

WireMock Spring Boot 1.0 has recently been released. Investigate if

• support can be added,
• whether JetBrains has any plan to add support for that in IDEA Ultimate,
• what kind of support may be added.

External links

• https://twitter.com/maciejwalkowiak/status/1637394531380342784
• https://github.com/maciejwalkowiak/wiremock-spring-boot

Summary

Direct links to documentation can speed up engineer's work of looking up information on a certain topic.

Tasks

• Add links to Handlebars helper documentation, in a Quick Documentation popup invoked on the name elements of Mustaches.
• The links should point to different sections on https://wiremock.org/docs/response-templating/
• This should be done after #14, because the reference contributor will result in a quick documentation popup as well, into which these links should be added.
  • If this is not possible, some alternative placement has to be found.

Summary

WireMock provides a way to verify stubs. This issue is to look into that area of WireMock and collect features that could be implemented in WireMocha to support.

Documentation

• WireMock - Verifying

Summary

WireMock 3.0.0-beta3 introduced support for URL path template variable:

• https://github.com/wiremock/wiremock/releases/tag/3.0.0-beta-3
• https://github.com/wiremock/wiremock.org-sources/blob/3.0.0-beta/_docs/request-matching.md#path-templates

Tasks

• Collect what kind of support can be added for this feature.

Feature candidates

• Update JSON schema of stub mappings to include all properties for the path templates.
  • Double-check beforehand, if the schemas in WireMock are also updated.
• Update duplicate URL property and call checker to include urlPathTemplate and urlPathTemplate().
• Inspection to report when the pathParameters property is specified but urlPathTemplate is not.
• Intention action to add urlPathTemplate property in JSON, and withPathParam() in Java DSL for all not configured path template variables.
  • JSON DSL
  • Java DSL
• Inspection to report the urlPathTemplate / urlPathTemplate() value if there is no path parameter in it.
  • JSON DSL
  • Java DSL
• Inspection to report if a path param in pathParameters is not a path variable in urlPathTemplate
  • JSON DSL
  • Java DSL

Summary

Code completion for Content-Type header value matchers.

Tasks

• Create a completion contributor to suggest values for matchers in withHeaders() calls for the Content-Type header, like below:

stubFor(
  get(urlEqualTo("/some/thing"))
    .withHeader("Content-Type", equalTo("application/x-www-form-urlencoded"))
    .willReturn(aResponse())
);

Resources

• https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Type

Summary

Although line markers/gutter icons are available for body file paths in both the JSON and Java DSLs, they are not used when doing usage/reference based search on mapping files.

By providing references to these string literals, the configured JSON properties and method calls will show up in usage based search results, which can also be beneficial when deleting mapping files, to notify users that those files are still in use.

Tasks

• Create reference contributors for the same JSON properties and method calls that the respective line marker providers provide for, and resolve to.

Summary

In WireMock

JSON equality matching is based on JsonUnit and therefore supports placeholders.

(see https://wiremock.org/docs/request-matching/#placeholders), so some highlighting could be added for these placeholders.

Tasks

• Create an annotator that can highlight JSON string literals in stub mapping files
  • in the format of ${json-unit.xyz}
  • when the string literal matches something like .*\$\{json-unit\..*}.*.
• Handle json strings that contain multiple of these placeholders.
• Take into account the combination with language injections like JSON in the equalToJson property.

Out of scope

• This task doesn't include any kind of language support for JsonUnit placeholders. It is not really the scope of this plugin.
• Java DSL is not included at the moment.

Summary

WireMock Cloud is WireMock's main product. This issue to investigate the capabilities of WireMock Cloud, and collect areas that could be integrated into WireMocha.

See if WireMock Cloud has a public API to do any kind of interaction, in the first place.

Summary

Revisit how the the JSON stub mapping files are recognized when the request.method, request.url* and/or request properties are missing.

At first glance, they will match any method and/or url, and having them missing might not be an invalid stub mapping file.

Summary

WireMock 3.0.0-beta5 is available at https://github.com/wiremock/wiremock/releases/tag/3.0.0-beta-5. Make sure to add support for those changes.

Tasks

• Default value validation for proxyTimeout: wiremock/wiremock#2058
• Default value validation for proxyPassThrough in wiremock/wiremock#2087
• request.clientIP attribute in response templating: wiremock/wiremock#2103
  • Add completion for clientIp.
  • Adjust code completion in general for request.

Summary

The HTTP Client plugin is available for IntelliJ IDEA Ultimate and paid IDEs, and it provides a way to compose, send and validate HTTP requests.

Tasks

• Create live templates for the request types in the WireMock Admin API.

Notes

• https://www.jetbrains.com/help/idea/http-client-in-product-code-editor.html

Summary

By default mappings are recognized in the src/test/resources folder, but the root directory can be overridden to use mappings placed elsewhere.

Tasks

• Provide a way for users to mark custom directories as root directories.
  • Optionally, the Project View could also display an alternate icon for these types of directories.
    • Icons candidates: DatabaseIcons/icons/virtualFolder, DatabaseIcons/icons/expui/virtualFolder
    • Layered icons
  • Functionality would this way be extended to other directories that users may use.
• Provide a UI (maybe in the plugin settings, maybe elsewhere) for users to specify their list of custom mappings directories.

Might be related

• https://wiremock.org/3.x/docs/standalone/java-jar/
• wiremock/wiremock#892
• wiremock/wiremock#1722

Summary

Since #36 made it possible to decompose entire multi-mapping files, it could also be useful to extract selected mappings from a multi-mapping file.

Tasks

• Create an intention action that would extract one selected mapping.
  • The intention action would be available only in multi-mapping files.
  • Since properly determining the contents of a selection in the editor brings a bit of challenge, the first iteration would limit the extraction to a single selected mapping, and would not yet allow extraction of multiple selected ones.
  • The intention would ask the user to specify the name of the new file the mapping will be extracted to.

To be clarified

• On what element the intention action should be available?
  • It might be something at the root of a mapping element, since mapping objects can be quite long.
  • Or when the caret is placed somewhere inside a stub-mapping JSON object, then that particular mapping would be extracted.

Summary

In stub mapping files, where only a single request-response mapping is defined within the mappings property can be simplified by unwrapping the mapping and removing the mappings property.

Tasks

• Create an inspection that can detect mappings properties with a single request-response mapping.
  • What about cases when the children look like this: request-response, response, request, none?
• Add quick fix to remove the mappings property like this:

//from
{
  "mappings": [
    {
       "request": { ... },
       "response" : { ... }
    }
  ]
}

//to
{
   "request": { ... },
   "response" : { ... }
}

• Make sure to keep any other properties specified.
• In case there is a meta property specified as well, besides mappings, don't report anything, because the meta might contain important properties that can be lost if users are not cautious enough when using the quick fix.

To be clarified

• Look into other properties if they need special care.

Summary

Handlebars language injection currently happens in a way that complete string literals are injected with Handlebars, even if only a portion of the literal is actually a Handlebars fragment.

Tasks

• Rework Handlebars language injection in both the Java and JSON DSLs, so that multiple Handlebars fragments can idependently be injected into the same string literal.

Summary

WireMock is capable of handling stateful behaviour via so-called Scenarios: https://wiremock.org/docs/stateful-behaviour/
Stubbings can be assigned to Scenarios and states along with a transition to a new state.

To ease the code implementation for a complete scenario flow, a custom generator could be created.

Tasks

• Come up with a dedicated syntax for scenario definitions. The following idea of syntax is based on https://blog.testproject.io/2020/03/09/simulating-rich-behaviour-using-advanced-wiremock-features-part-4/

Stateful Checkout //scenario name
POST /checkout Scenario.STARTED //a state with its stubbing without transition
POST /addtocart Scenario.STARTED -> "SHOPPING_CART_CONTAINS_ITEMS" //a transition between states
POST /checkout "SHOPPING_CART_CONTAINS_ITEMS"

• Implement a tool window with a split view in which on the left side this special scenario definition could be edited, while on the right side, the generated Java or JSON stubbing code would be displayed.

Notes

• By default the generated stub mapping would return a 200 response code. The customization of that might be added later to the syntax.

Summary

An inspection could be implemented that can detect duplicate withQueryParam() calls in RequestPatternBuilder.

Tasks

• Create an inspection that would report multiple withQueryParam() calls with for the same query param name in the same call chain.
• Create quick fix as well to deduplicate those calls.

Summary

The intention action that converts withBody(String) calls to withBase64Body(String) calls now supports only single String instances.

Tasks

• Extend the intention to support conversion when the argument consists of multiple concatenated strings, e.g.

withBody("{\n" +
"  \"property\": {\n" +
"    \"someKey\": \"someValue\"\n" +
"  }\n" +
"}")

• This will be supported only when all parts of the concatenation is a String literal, character literal, or a String constant that can be evaluated.

• Extend the intention to support text blocks, e.g.

withBody(
"""{
  "property": {
    "someKey": "someValue"
  }
}""")

• Explore and collect other WireMocha features that could be improved the same way.

Summary

There is an inspection in place that reports duplicate withHeader() calls for the same header name in the same call chain.

Tasks

• To simplify deduplication, a quick fix should be added to remove all duplicate withHeader() calls except the selected one.
• The intention name could be something like: Deduplicate keeping this withHeader() call.

Summary

There are a handful of JSON properties that are, at the moment, not included in the stub mapping schema. This is true for this plugin, and seemingly for the schemas in WireMock itself.

Tasks

• Identify the list of missing properties and add them to the schema.
• Create a pull request in WireMock to add these properties there too.
  • If the PR is merged, open another PR to update the schemas in the WireMock documentation repo as well.

List of missing properties

• request.scheme, request.port, request.host, request.customMatcher, request.multipartPatterns (see com.github.tomakehurst.wiremock.matching.RequestPattern).
• Within request.multipartPatterns (see com.github.tomakehurst.wiremock.matching.MultipartValuePattern):
  • name, matchingType, headers, bodyPatterns

References

• wiremock/wiremock#2178

Summary

WireMock.NET is a library for .NET users for API mocking. Although it is separate from WireMock, it mimics its functionality.

Tasks

• Look into the ReSharper SDK and WireMock.NET, what would be required and necessary to add support for WireMock.NET.
• Potential topics:
  • Whether support could be added within the WireMocha plugin, or a separate plugin would need to be developed.
  • Obfuscation for .NET code.
  • Upon plugin install, or first launch after install, the plugin would disable functionality that is not relevant in the current IDE, e.g. being installed in Rider, only WireMock.NET features would be enabled, in IntelliJ, only WireMock ones.

Resources

• R# SDK
• ReSharper Rider Plugin Template
• WireMock.NET
• WireMock.NET - Introduction

Summary

When e.g. withStatus(200) is called on a convenience method that already covers setting the expected status, e.g. ok(), okJson() or a similar one, the withStatus(200) call is superfluous and may be removed.

Tasks

• Collect withStatus to convenience methods mappings that should be reported.
• Create new or extend existing inspection with the reporting logic.
• Add quick fix to remove the extra withStatus() call.

Summary

WireMock provides a request model for Handlebars helpers via the request parameter: The request model

Tasks

• Add completion to mustache parameters after request. texts.
• Include a short description about each request attribute in the code completion items.

Summary

Since stub mapping files can be named as users like, those file names might not communicate enough/proper details about what (request and response data) those mapping files contain or reference.

This may be made more difficult by the fact when there is a myriad of stub mappings in a folder.

This can obviously be solved by naming the mapping files in a way that includes relevant information, but since this might not happen, additional details could be added to mapping file nodes in the IDE's Project View. Similar to the timestamp display here.

Tasks

• Create a decorator for the JSON stub mapping files in the Project View.
  • The decorator would by default display the following information.
    • in case of single-mapping files: [request.method] [request.url|urlPath|urlPattern|urlPathPattern] -> [response.status], e.g. POST /some-url -> 200
    • in case of multi-mapping files: multiple mappings
    • in case of mapping files that don't have a mappings or request property: empty mapping
  • Long urls would be truncated with ellipsis (...) after X (value TBD) characters. For example: POST /some-really-long-url... -> 201
• A toolbar menu/option would be availab to enable/disabled the stub mapping data display.

Nice to have

• Options, so that users could customize what request and response properties to display on the file nodes.

Summary

The WireMock mapping JSON schemas for requests says that

Only one of url, urlPattern, urlPath or urlPathPattern may be specified.

Tasks

• Create an inspection that can detect duplicate url pattern definitions.
• Only in the JSON DSL.
• Add a quick fix to deduplicate them, just like in case of body and header definitions.

Summary

Merging a set of mapping files might be useful for easier reorganization or re-categorization of mappings.

Tasks

• When selecting 2 or more mapping files in the Project View, the one the context menu is invoked on would have an action like Move mappings into this.
  • This action would be displayed only when there are at least 2 mapping files selected.
  • The selected files don't have to be in the same mappings folder, but they must be mapping files in mappings folders.
• Implement an action to merge all mapping files within a mappings folder.
  • This would be a context menu action on mappings folders.
  • The context menu action would be displayed only when there is more than 1 mapping file in it.
  • This would create a completely new mapping file in the selected folder, with the contents of all mappings in that folder. Then it would delete all other mapping files.
    • The name of the new file could be specified users.

Summary

There is already an inspection that can detect duplicate withHeader() calls in ResponseDefinitionBuilder. The same could be implemented for request creation via RequestPatternBuilder.

Tasks

• Create an inspection that would report multiple witHeader() calls with for the same header name in the same call chain.
• Create quick fix as well to deduplicate those calls.
• withoutHeader() may need to be taken into account depending on how it actually behaves.

Summary

Currently request Content-Type header values are code completed, but not response ones.
There is a distinction between the two: request headers must be specified with matchers, while response headers must be specified with exact string values.

Tasks

• Extend the current header code completion to work for response headers.

There is an error thrown by the IntelliJ Platform when editing string literals injected with the Handlebars language.

java.lang.AssertionError: Before patch: doc:
'{{#\"aJson\": \"string\"}}'
---PSI:
'{{#\"aJson\": \"string\"}}'
---chars:
'{{#"aJson": "string"}}'.
OK let's see. Host file: PsiJavaFile:WireMochaDemo.java in 'D:\Git\...\WireMochaDemo.java' (Language: JAVA)  (uncommitted)
Was injected Language: Handlebars at ranges: [Shred in PsiLiteralExpression:"{{#\"aJson\": \"string\"}}" with range (496,524) (class com.intellij.psi.impl.source.tree.java.PsiLiteralExpressionImpl) inside range (1,27)]
	at com.intellij.psi.impl.source.tree.injected.InjectionRegistrarImpl.parseFile(InjectionRegistrarImpl.java:693)
	at com.intellij.psi.impl.source.tree.injected.InjectionRegistrarImpl.reparse(InjectionRegistrarImpl.java:613)
	at com.intellij.psi.impl.source.tree.injected.InjectedLanguageUtil.reparse(InjectedLanguageUtil.java:333)
	at com.intellij.psi.impl.PsiDocumentManagerImpl.reparseChangedInjectedFragments(PsiDocumentManagerImpl.java:175)
	at com.intellij.psi.impl.DocumentCommitThread.doCommit(DocumentCommitThread.java:273)
	at com.intellij.psi.impl.DocumentCommitThread.commitUnderProgress(DocumentCommitThread.java:136)
	at com.intellij.psi.impl.DocumentCommitThread.lambda$commitAsynchronously$0(DocumentCommitThread.java:79)

It is most probably related to the \ escaping character, because it is thrown when the string contains that.

Summary

WireMock has its custom helpers for Handlebars: https://wiremock.org/docs/response-templating/

Tasks

• Implement code completion for the following items:
  • helper names
  • supported hash names within helpers
  • allowed values of given hashes

The Java stubbings and JSON stub mappings are interchangeable, at least to a certain extent.

Investigate and collect information on

• in what form and what extent Java code could be converted to JSON, in terms of stub mappings,
• how POJOs from WireMock could be used to store the data, and how they may be deserialized into JSON
  • The StubMapping object might be my friend here.
  • I'll have to take into account stub mapping JSON schemas and potential modifications in them that the Java/JSON conversion has to reflect.
• whether the conversion should be in a tool window, dialog window, intention action, menu action, etc.
• if at first it should be delivered as an incubator/experimental project, with plugin settings to enable/disable it

Summary

WireMock can handle Handlebars templates, see Response Templating, thus language injection could make working with such templates easier.

Tasks

• Look into how language injection works in JSON files.
• Collect Java methods and JSON mapping properties where Handlebars templates can be used. (at least for testing purposes)
• Find out how only a selected part of a string literal can be injected a certain language.
• Find out how Handlebars (or other languages) can be injected within an already injected language.

Resources

• Handlebars/Mustache IntelliJ plugin (provides Handlebars language support): https://plugins.jetbrains.com/plugin/6884-handlebars-mustache
• https://handlebarsjs.com
• Example injection:
  https://github.com/patricklx/intellij-emberjs-experimental/blob/master/src/main/resources/hbs-injection.xml

Summary

The Handlbars inspections introduced in v1.0.2 didn't include quick fixes. They should be added.

Tasks

• Add quick fixes for the following problems:
  • Missing mandatory hash -> add hash
  • Redundant hash value -> remove hash altogether
  • No parameter is supported by a helper -> remove all parameters except hashes
  • Hash is not supported by helper -> remove hash altogether

Summary

WireMocha has been supporting IntelliJ since version 2021.3, but to be able to provide better functionality and performance, 1.0.12 will be the first release in which 2021.3 will no longer be supported.

From that version of WireMocha on, with each new major release of IntelliJ, the earliest supported major IDE version will be dropped and bumped.

Summary

Since response bodies can be stubbed multiple ways (string literal, base64, file path), having multiple of them specified may lead to confusion which one would actually be applied.

Thus, an inspection would be useful to report if they are specified/called in multiple ways.

Tasks

• Implement inspections for the JSON and Java DSLs to validate response body specification.
• On JSON side, only one of them must be allowed.
  • Checking the duplication of the same key is not required, since it is done automatically by the IDE.
• On Java side it is also true that only one of them must allowed.
  • Here, duplicate calls to the same with*Body*() call has to be validated too.

Resources

• List of response body keys in JSON: body, base64Body, bodyFileName, jsonBody
• List of response body calls in Java: withBody, withBase64Body, withBodyFile, withJsonBody

Considerations

• As for the JSON DSL, if the schema definition language allows it, this might be a possible validation to be implemented in the schemas themselves, in the future.

Summary

One might want to reorganize multi-mapping files, and have a more granular mapping file structure.

Tasks

• Create a context menu action in the Project View called something like Decompose into single-mapping files....
  • The action would be displayed only for mapping files that actually contain multiple mappings. For this the data based on which the Project View node decoration is displayed, can be reused here.
  • This action would create a single-mapping file in the same directory, for each mapping in the source multi-mapping file.

To be clarified

• How to ask users to specify the names of the newly created files?
  • Should there be a default file name format?

Summary

The same (or most of the) language injections that are done on the Java side could be added and configured in the json mappings as well.

To be clarified

• Look into how language injection works in JSON files.
• Collect the JSON mapping properties where languages can be injected.

Resources

• Investigate adding Handlerbars language injection support
• WireMocha language injections

Summary

Easy navigation to the implementation of customs helper may be useful, instead of having to look up separately where they are implemented.

Tasks

• Create a reference contributor that will bind com.github.tomakehurst.wiremock.extension.responsetemplating.helpers.WireMockHelpers enum constants to the name parts of Mustaches. This will make is possible to navigate to those constants via Ctrl+click.

To be clarified

• Check if and how the reference contributor will result in a proper "find usage" functionality.