Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

VSCode ref jump feature does not work when dataform project is located under the subdirectory #1779

Open
moker-spaghetti opened this issue Jul 7, 2024 · 2 comments
Labels

Comments

@moker-spaghetti
Copy link
Contributor

Expected Behavior

VSCode ref jump feature should work on dataform projects located under the subdirectories, if successfully compiled.
(To compile, project location should be specified in the first element of the vscode config dataform.copmilerOptions, added in #1639)

Current Behavior

You can click ${ref(...)}, but it opens a file not existed since it ignores root dir of dataform project.

Possible Solution

Most simple solution would be adding a configuration or gettting the current project location on the ref click feature.
It would be nice if we could support multiple dataform projects in subdirectories or multi-root workspace at the same time.

Environment

OS: Win11
dataformCoreVersion: 3.0.0
Dataform CLI version: 3.0.0
VSCode extension version: 0.0.14

@moker-spaghetti moker-spaghetti changed the title VSCode ref jump feature dows not work when dataform project is located under the subdirectory VSCode ref jump feature does not work when dataform project is located under the subdirectory Jul 7, 2024
@ashish10alex
Copy link
Contributor

I have attempted to build subdirectory support in my own VSCode extension (see these lines) by searching for the first instance where I can find workflow_settings.yaml going backward from the current directory of the active editor. Although this solution works for go to definition & compilation etc. This will slow down things by a few milliseconds.

@Ekrekr
Copy link
Contributor

Ekrekr commented Aug 16, 2024

I think this may have been fixed by #1769 - I'll ping @GJMcGowan to publish a new version when he's back

@Ekrekr Ekrekr added the bug label Aug 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants