Goto definition and autocomplete is broken for some imports when HardHat config is present

[emo-eth]

I run into this often in dual hardhat/foundry repos, and usually just delete the hardhat.config.ts file while working, since many of the LSP features I rely on break because the hardhat plugin defaults to loading the hardhat config with no way to configure which it prefers.

This is true even when the project uses HardHat 2 - possibly related to #709

Repro steps:

• npx create-lz-oapp@latest --example oapp
• Open MyOapp.sol
  • Observe @layerzero imports do not have goto definition nor autocomplete
  • For some reason, @openzeppelin imports do work
  • 
  • 
  • 
• Delete hardhat.config.ts or rename to hardhat.config.ts.bak
• Restart extensions so the HardHat plugin loads the foundry.toml config instead of the HardHat config: > Developer: Restart Extension Host
  • Observe all imports support goto definition
  • Observe autocomplete for imports work
  • 
  • 

I only have the HardHat extension installed for Solidity files:

 cursor --list-extensions
adpyke.codesnap
anysphere.cursorpyright
anysphere.remote-containers
asvetliakov.vscode-neovim
bierner.markdown-mermaid
biomejs.biome
bradlc.vscode-tailwindcss
charliermarsh.ruff
connorshea.vscode-ruby-test-adapter
eamodio.gitlens
esbenp.prettier-vscode
github.vscode-github-actions
github.vscode-pull-request-github
golang.go
hbenl.vscode-test-explorer
jdinhlife.gruvbox
jeff-hykin.better-nix-syntax
jock.svg
ms-azuretools.vscode-containers
ms-azuretools.vscode-docker
ms-python.debugpy
ms-python.python
ms-python.vscode-pylance
ms-toolsai.jupyter
ms-toolsai.jupyter-renderers
ms-toolsai.vscode-jupyter-cell-tags
ms-toolsai.vscode-jupyter-slideshow
ms-vscode.hexeditor
ms-vscode.live-server
ms-vscode.test-adapter-converter
ms-vscode.vscode-github-issue-notebooks
nomicfoundation.hardhat-solidity
nrwl.angular-console
pest.pest-ide-tools
redhat.java
redhat.vscode-yaml
rust-lang.rust-analyzer
ryanluker.vscode-coverage-gutters
ryuta46.multi-command
sainnhe.gruvbox-material
shopify.ruby-lsp
sorbet.sorbet-vscode-extension
tamasfe.even-better-toml
tintinweb.graphviz-interactive-preview
tomoki1207.pdf
vadimcn.vscode-lldb
vscjava.vscode-gradle
vscjava.vscode-java-debug
vscjava.vscode-java-dependency
vscjava.vscode-java-pack
vscjava.vscode-java-test
vscjava.vscode-maven
vscodevim.vim
yoavbls.pretty-ts-errors
yzhang.markdown-all-in-one

I understand why the HardHat Solidity extension would default to HardHat over Foundry when both are present - but I'd love the option to toggle between preferring one or the other. Even if this were fixed, I always default to Foundry-first config, and yours is the best LSP available by a wide margin 😅

[emo-eth]

This is true sometimes even when hardhat.config.{js,ts} is present in a nested dependency. It breaks autocomplete and goto definition for the whole project.

Of course, I tried recreating in a fresh Forge project by installing one of the dependencies giving me issue, but ran into no issues. But it definitely happens sometimes.

[kanej]

Hey @emo-eth thanks for the feature request.
The extension analyzes your entire workspace looking for "projects", it then associates Solidity files with the identified projects. For each project it determines whether it is a Hardhat, Foundry or Hybrid project. When you delete the hardhat config file you, the project is going to switch from hybrid to pure Foundry.
My understanding of the feature request is a toggle to force a project to be Foundry?
Can I ask, is the metadata different between the Hardhat setup in the project and the Foundry? I am trying to understand whether the issue is different setups of, for instance which folder is the contracts folder, or whether the issue is that the Foundry project type has different logic that works for your project that the Hybrid project type lacks.

[emo-eth]

@kanej Not sure how hardhat and foundry defaults diverge - but I'd assume that LayerZero has done their best to set the same configs for Hardhat and Foundry in their example repos. I find it odd that autocomplete is broken for some imports/remappings and not others - makes me think dependencies have something to do with it (incorrectly initialized/package dependencies?)