Search Terms
autocomplete absolute path
Suggestion
When using autocomplete in VS, sometimes the plugin inserts relative paths instead of absolute paths. Add a setting so that it will always insert absolute paths.
Use Cases
Our project has a firm rule to always use absolute paths as they make refactoring much easier. Currently we have a step in code review to check for accidental relative paths but it would be nice if this was not needed.
Examples
When I open a new Typescript file in VS, I start to write a function, and one of the argument types has not been imported, so the autocomplete list comes up. When I pick an item from the list, if the setting is set, the automatically inserted import is guaranteed to be absolute.
Absolute here means "relative to project root" (relative to baseUrl would also work for me as we set that to project root).
Checklist
My suggestion meets these guidelines:
[x] This wouldn't be a breaking change in existing TypeScript / JavaScript code
[x] This wouldn't change the runtime behavior of existing JavaScript code
[x] This could be implemented without emitting different JS based on the types of the expressions
[x] This isn't a runtime feature (e.g. new expression-level syntax)
Search Terms
autocomplete absolute path
Suggestion
When using autocomplete in VS, sometimes the plugin inserts relative paths instead of absolute paths. Add a setting so that it will always insert absolute paths.
Use Cases
Our project has a firm rule to always use absolute paths as they make refactoring much easier. Currently we have a step in code review to check for accidental relative paths but it would be nice if this was not needed.
Examples
When I open a new Typescript file in VS, I start to write a function, and one of the argument types has not been imported, so the autocomplete list comes up. When I pick an item from the list, if the setting is set, the automatically inserted import is guaranteed to be absolute.
Absolute here means "relative to project root" (relative to baseUrl would also work for me as we set that to project root).
Checklist
My suggestion meets these guidelines:
[x] This wouldn't be a breaking change in existing TypeScript / JavaScript code
[x] This wouldn't change the runtime behavior of existing JavaScript code
[x] This could be implemented without emitting different JS based on the types of the expressions
[x] This isn't a runtime feature (e.g. new expression-level syntax)