typecheck: use domains from config when checking types
It's very possible that I'm just going about this all wrong, but I'm trying to set up my workspace config so that typecheck includes types from domains that I've specified in the config file (my code executes entirely within the context of one domain). So far I haven't been able to make this work, and I'm not sure if its something I'm doing incorrectly, or if the "domains" config value is unused during typechecking. I'm leaning towards it not being used, as I tested out some invalid values under "domains", and received no complaint from solargraph. Any assistance clarifying the intended behavior would be much appreciated.
My command:
bundle exec solargraph typecheck --level strict
My Config (with sample domain):
include:
- "**/*.rb"
exclude:
- spec/**/*
- test/**/*
- vendor/**/*
domains:
- "Module::Hierarchy::Here"
reporters:
- typecheck:strict
- require_not_found
- rubocop
formatter:
rubocop:
cops: safe
except: []
only: []
extra_args: []
plugins: []
max_files: 5000
Apologies if any of my terminology here is terrible, I'm not much of a Ruby dev.
The domains setting (and the @!domain directive) imports public instance methods from classes and modules. Its intended use is to provide code intelligence for certain types of DSLs. It was occasionally useful in some older versions of Solargraph, but I rarely use it anymore and might drop support for it in a future version.
Can you give me an example of what you're trying to accomplish, e.g., the analysis you expect vs. what actually happens? I might be able to suggest an alternative solution.
Certainly, my code is running within the context of a specific class/module and thus has access to methods within that module without using any module identifiers. So for example there might be a module like Pkg::Sdk::Http with methods like 'get', 'post', etc., and in my code instead of writing it as Pkg::Sdk::Http.get, it'd just be get.
And I'm looking for solargraph to recognize this get method during typechecking and understand that it is available within the context where the code will be run. For now I've gotten around this by including a 'globals' file that "includes" all of the same modules at the root level, which actually seems to work, but only if typechecking the base project directory (for any sub-directories, this 'globals' file is not present so it doesn't get processed)