For large projects, it can make sense to have very customized VSCode extensions that are tightly coupled to specific patterns and policies within the codebase and aren't meaningfully generalizable. Currently there isn't a great solution for these use-cases:
publishing to public marketplace creates unnecessary clutter and isn't viable for anything "secret" to an org
publishing to an internal marketplace creates extra a lot of extra overhead and cost to essentially boomerang an extension back its only relevant project
distributing vsix packages is inelegant at scale and loses the ability to automatically propagate updates to users
Ideally a project could define its own extension(s) in the .vscode/ directory and have that extension be automatically loaded and activated when working within its workspace. This would enable a much more streamlined project+extension integration and effortless propagation of updates to users. There are some edge-cases that would have to be considered, like how to trigger reloads of extension during forward development or branch switching and whether users can opt out of the extension.
This could also have the side-effect of making some initial extension development easier in general, as work could be started directly against the codebase that inspired the idea before being split out into its own standalone project.
For large projects, it can make sense to have very customized VSCode extensions that are tightly coupled to specific patterns and policies within the codebase and aren't meaningfully generalizable. Currently there isn't a great solution for these use-cases:
vsix
packages is inelegant at scale and loses the ability to automatically propagate updates to usersIdeally a project could define its own extension(s) in the
.vscode/
directory and have that extension be automatically loaded and activated when working within its workspace. This would enable a much more streamlined project+extension integration and effortless propagation of updates to users. There are some edge-cases that would have to be considered, like how to trigger reloads of extension during forward development or branch switching and whether users can opt out of the extension.This could also have the side-effect of making some initial extension development easier in general, as work could be started directly against the codebase that inspired the idea before being split out into its own standalone project.