feat: projectless validation

[antico5]

trafficstars

The scope of this PR is to provide validation to hardhat files not belonging to a hardhat project. This includes files in directories not belonging to hardhat, as well as random solidity files open in the editor.

Besides handling these cases, the PR involves the implementation of a particular abstraction between the LSP and "framework providers", to facilitate the inclusion of other providers in the future, while reusing the most code on the LSP side. The "Projectless" implementation works as an adapter as well.

Some concerns that may come up and why I implemented them that way:

• On ProjectlessCompilationBuilder._crawlDependencies, there are calls to the analyzer. This can be refactored or a better abstraction could be in place. In theory, indexing and analysis happens before validation, but this was needed because you can open a random solidity file that has dependencies, but be on a completely different folder in your workspace.
• Lookup of hardhat.config file bundled with the extension. Depending whether you are running the extension in dev mode, running unit tests, or running from a final packaged version, the mandatory hardhat.config file that we need to invoke hardhat tasks can be located in different places, so there's some lookup logic for that in CompilationService
• ProjectlessIndexer is not called from indexWorkspaceFolders, as we planned to. When discussing this, ideally we wanted the LSP to not know about any adapter, even the Projectless one, but on a scenario where you open an external solidity file (not in workspace), it was not analyzed and we have no project associated to it. So I solved this by having ProjectlessProject be the kind of fallback project when no other project is associated to a sol file.
• OutputConverter is duplicating some of the logic present in other parts of the code. Eventually this should be refactored into having a single source of logic for validation results, including both framework-specific and agnostic results.
• A new flag was introduced to prevent validation happening before indexing finished. This is because when a file is opened, it's attempted to be validated. If we did this before indexing finishes, a file can be identified as Projectless and be validated using that strategy. But after indexing, it could turn out that it was a hardhat contract so it was meant to be validated differently, and for that amount of time it could show wrong diagnostics (i.e. unexisting import).

[linear[bot]]

HHVSC-224 Spike of projectless sol file validation worker

This is an investigation task. The intent is to spike out a worker process and supporting code for "projectless" solidity files.

There are two goals:

• to feedback into the api in https://www.notion.so/nomicfoundation/Making-the-Nomic-VSCode-Extension-tool-agnostic-3f595c861e834e4f9b2dbc4354035b88
• to determine if we can provide something similar to Juan Blanco's solidity for lone solidity files (https://docs.soliditylang.org/en/latest/using-the-compiler.html#base-path-and-import-remapping)

Suggestions (report back if they don't make sense)

• one "projectless" worker per language server (I suspect)
• assume the import resolution rules are those of the solc command line
• use hardhat for compiler download

Test Scenarios

1. Create a folder with ./src and ./lib subdirectories and populate with solidity contracts
2. a .sol file within a hardhat project but under ./test instead

Not supported

• remappings.txt
• path prefix for solc

Our attempts to specify an api for external tools (https://www.notion.so/nomicfoundation/Making-the-Nomic-VSCode-Extension-tool-agnostic-3f595c861e834e4f9b2dbc4354035b88) is still in flux. Concentrate on the worker and a minimally working validation, then we can sync and discuss how the api has to change. The main api to build around is resolveSolcInput in the worker, we can look at integration with navigation and project structure after that.

[codecov-commenter]

Codecov Report

Merging #267 (e1da69d) into development (bd29eb2) will decrease coverage by 0.48%. The diff coverage is n/a.

@@               Coverage Diff               @@
##           development     #267      +/-   ##
===============================================
- Coverage        70.11%   69.63%   -0.49%     
===============================================
  Files              170      178       +8     
  Lines             4133     4265     +132     
  Branches           726      738      +12     
===============================================
+ Hits              2898     2970      +72     
- Misses             996     1061      +65     
+ Partials           239      234       -5     

Impacted Files	Coverage Δ
src/parser/analyzer/resolver/index.ts	50.00% <0.00%> (-8.34%)	:arrow_down:
src/services/validation/validate.ts	91.89% <0.00%> (-4.74%)	:arrow_down:
...vices/validation/worker/build/buildInputsToSolc.ts	95.87% <0.00%> (-2.00%)	:arrow_down:
src/server.ts	87.69% <0.00%> (ø)
src/utils/findProjectFor.ts	100.00% <0.00%> (ø)
src/services/validation/analyse.ts	100.00% <0.00%> (ø)
src/utils/getOrInitialiseSolFileEntry.ts	100.00% <0.00%> (ø)
src/services/initialization/onInitialized.ts	63.33% <0.00%> (ø)
src/projects/Projectless/ProjectlessProject.ts	70.58% <0.00%> (ø)
src/projects/Projectless/ProjectlessIndexer.ts	0.00% <0.00%> (ø)
... and 12 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[antico5]

This PR is deprecated after the framework-agnostic refactor. Projectless was included and updated with a few changes on the big refactor