You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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
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
andcheckout/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.The text was updated successfully, but these errors were encountered: