Intellisense stops working if there are any problems with hardhat.config.js or hardhat.config.ts

[calmacfadden]

Intellisense will not work at all if there are any problems in the hardhat config file.
This happens if it is a misconfigured module export. For example a missing closing curley bracket

module.exports = { solidity: "0.8.27"

It also happens if any require or import (for typescript) is invalid. For example the below require is missing the x in toolbox.

require("@nomicfoundation/hardhat-toolbo");

/** @type import('hardhat/config').HardhatUserConfig */
module.exports = {
  solidity: "0.8.27"
}

It also breaks if any of the imported packages or files have bugs in them. This is the biggest cause of annoyance. I am working on quite a large project with dozens of imports in my hardhat configuration and anytime anyone breaks one of the libraries it kills productivity until it is resolved. It also makes identifying the cause very difficult as you cannot navigate the project with intellisense.

It would be helpful if intellisense worked to some degree if there are problems with the hardhat config, ideally it should work fully but i understand that may not be possible as knowing the solidity version may be necessary. At a minimum i think "Go to Definition" should work correctly when used on a solidity line like this "import "./Test2.sol";"

[kanej]

We load the hardhat.config.{js,ts} within the extension to build up a picture of the project (e.g. contract folders are here etc).
Currently if identify that we have a Hardhat project but we fail in loading the hardhat.config.{js,ts} in the ways mentioned above, then our intellisense is broken. We don't have the project information to run our analysis.
An option would be to make some fallback assumptions in the case where we can't load the config file i.e. if there is a ./contracts assume that this is the relevant folder.
This needs a deeper investigation to assess the implications though.
It should be said that Hardhat v3 is looking to make the config files significantly more robust against these sorts of loading issues, which should hopefully reflect in a better VSCode experience.