Nested folder needs restart to enable elm-tooling

[AlienKevin]

Summary

After I created a new subfolder containing an elm project in VS Code, I have to restart it to enable elm-tooling.

Expected Behavior

Elm-tooling can scan for newly added elm.json files and start running when new projects are added.

Note

This issue is different from #94. I'm not creating a subproject under another elm project. It's simply that the project folder is nested under the working directory.

Your Environment

• Version used:
  Version: 1.45.1 (user setup)
  Commit: 5763d909d5f12fe19f215cbfdd29a91c0fa9208a
  Date: 2020-05-14T08:27:35.169Z
  Electron: 7.2.4
  Chrome: 78.0.3904.130
  Node.js: 12.8.1
  V8: 7.8.279.23-electron.0
  OS: Windows_NT x64 10.0.19041

[razzeee]

Did you open an elm file? That's our start condition right now.

[AlienKevin]

I did, but elm-tooling doesn't run on that file.

[razzeee]

Can you do an example zip file that we can use to debug this?

[youlam]

I don't know if this is the same issue but I'll post here. (Sounds similar, otherwise let me know I'll open a separate issue.)

Say I have A/B/src/Main.elm where folder B contains the elm.json file.

Then if I open any of A, A/B/src, or A/B/src/Main.elm directly from the command line and (in the first two cases) open Main.elm from with VSCode, elm-tooling is inactive, including simple stuff like elm-format on save.

The only thing that gets elm-tooling to work is to open A/B from the command line, i.e., the folder that contains the elm.json.

Personally I'd simply like elm-tooling to work for any elm file, and for elm-tooling to be smart enough to find the relevant elm.json file on its own, if it can, without my having to open exactly the right "root" folder in VsCode.

[razzeee]

I agree in general. But context matters here unfortunately. If your project A references B it will work fine with tooling as far as I know.
If you just happen to checkout another elm project there it won't work. As you elm.json doesn't reference it.

[youlam]

I'm no expert, but why can't elm-tooling simply detect the presence of an elm file, and then walk up the directory tree to find the nearest elm.json, if it even needs that? Why base all decisions off of the elm.json (or lack thereof) found in the VSCode window directory, instead of basing decisions off of the current file?

In particular, shouldn't one be able to open an elm file directly (i.e., not even open a directory at all), and be able to get some functionality such as format-on-save?

Again I'm no expert really, but this just seems like the most intuitive desirable behavior to me. In Sublime Text for example the "Elm Format on Save" extension simply does its thing on every Elm file, elm.json or no elm.json.

[razzeee]

I'm no expert, but why can't elm-tooling simply detect the presence of an elm file, and then walk up the directory tree to find the nearest elm.json, if it even needs that?

This would be problematic, as would compute vastly different language helpers based on this and there are actually use cases where you want to look at code, not with the nearest elm.json.

Why base all decisions off of the elm.json (or lack thereof) found in the VSCode window directory, instead of basing decisions off of the current file?

It's not only the one in the "vscode window directory", but every directory, that has no elm.json in a parent folder (until you reach the folder you've loaded)

In particular, shouldn't one be able to open an elm file directly (i.e., not even open a directory at all), and be able to get some functionality such as format-on-save?

Some, but most of the interesting functionality will need the context and Elm doesn't really work without a project anyway. So it's not like many users will ever use it that way.