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

Improve support for searching with relative paths in a monorepo #150452

Closed
DavidGoldman opened this issue May 26, 2022 · 2 comments
Closed

Improve support for searching with relative paths in a monorepo #150452

DavidGoldman opened this issue May 26, 2022 · 2 comments
Assignees
Labels
*duplicate Issue identified as a duplicate of another issue(s)

Comments

@DavidGoldman
Copy link
Contributor

DavidGoldman commented May 26, 2022

For very large monorepos, it's not feasible to give VS Code the monorepo root (e.g. checkout/mycompanyname) since it's infeasible to have VS Code search the entire monorepo - it's too big.

So instead, folks create workspaces containing multiple relatively small folders inside the monorepo (e.g. checkout/mycompanyname/mobile/iphone/MyProject and checkout/mycompanyname/mobile/iphone/shared/SharedFramework). This allows VS Code to easily find files inside of these folders since VS Code will index the small folders without issue, although I've opened #150450 to improve this.

However, a problem occurs now when a user tries to jump to a file using a relative path from the base of the monorepo, e.g. mobile/iphone/shared/UIKitAdditions/UIView+Accessibility.swift since it doesn't exist in the VS Code project. VS Code only includes relative path results from the workspace folders here, but this doesn't work for this monorepo relative path since VS Code doesn't know about the monorepo root.

Ideally, we can provide VS Code with a path to the monorepo root (checkout/mycompanyname in this example), and it can use this to resolve relative paths above without needing to index the entire monorepo. Additionally, it might be useful to use the parent dir name (checkout in this example) as the folder name for the monorepo in case people have multiple named checkouts. This would ideally simplify the rendered item path in the UI (e.g. checkout/relative/path vs. checkout/mycompanyname/relative/path vs. /some/path/to/the/checkout/mycompanyname/relative/path), just like is done for files in workspace folders.

@ashgti
Copy link
Contributor

ashgti commented May 31, 2022

This is related to #73524 as well I think. If that API was available then it might be possible to work around this in an extension.

@roblourens
Copy link
Member

We've discussed how to make this scenario better. A lot of people use multiroot workspaces for working on a subset of a monorepo. Probably instead of a multiroot workspace you want to open the monorepo with only a subset of folders included, and the rest ignored. You can sort of do this with files.exclude but here is an issue for something better: #41860. I think that is the right solution, not searching paths outside of the workspace folders in a multiroot workspace, I will close this as a duplicate of that issue

@roblourens roblourens added the *duplicate Issue identified as a duplicate of another issue(s) label Jun 1, 2022
@github-actions github-actions bot locked and limited conversation to collaborators Jul 16, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
*duplicate Issue identified as a duplicate of another issue(s)
Projects
None yet
Development

No branches or pull requests

3 participants