Make the file-type/extension provider authoritative for dynamic extensionless file associations (follow-up)
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 52/100
- Issue type
- Refactor
- Clarity
- Mostly clear
- Activity status
- Quiet
- Tech stack
- typescript, vscode
- Domain
- tooling
Research direction
Locate the extension/file-type provider and the separate dynamic extensionless-association lookup, then trace their callers in the main extension and unit tests. Compare the provider and host-level approaches described in the issue; done means the central lookup handles these associations and both consumers continue to work.
Written by the indexing model from the issue text.
Description
Follow-up to an earlier change that stopped tag-parsing non-included extensionless files.
Currently, dynamically discovered extensionless file associations are handled via a separate lookup outside the main file-type resolution path. Fold these into the extension/file-type provider so that the central file-type lookup is the single source of truth, rather than relying on a pre-built known list plus a separate check.
Why: As more code is unified onto the shared path, the common code won't know about these extra extensionless files unless they're part of the standard file-type resolution call. Keeping it in one place avoids divergence.
Approach options:
- Subclass/extend the extension provider and override the lookup to augment or replace the defaults, or
- Override at the host level: call the default provider first, and if it returns "none" and the file has no extension, fall back to checking the custom list.
Note: There are two consumers to keep working — the main extension and the unit tests.
Internal task number: 3021361
- Dominant language
- TypeScript
- Stars
- 6.2k
- Forks
- 1.7k
- Avg merge
- 1d 4h
- Merged PRs (30d)
- 60
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from microsoft/vscode-cpptools
-
more info needed
microsoft/vscode-cpptools#14793 · 1 comment · 1 assignee ·
-
more info needed
Difficulty 4/5 3-5 days Newbie friendliness 35/100
microsoft/vscode-cpptools#14787 · 1 comment · 1 assignee ·
-
[Bug] cpptools fails to start on Ubuntu ARM64 due to missing execute permissions on shared libraries Openbug fixed Language Service regression
microsoft/vscode-cpptools#14779 · 1 comment · 1 assignee ·
-
Language Service more info needed
microsoft/vscode-cpptools#14778 · 1 comment · 1 assignee ·
-
Feature Request Language Service parser
Difficulty 4/5 3-5 days Newbie friendliness 64/100
microsoft/vscode-cpptools#14769 · 1 comment ·
All issues in microsoft/vscode-cpptools
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
bug v2
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
modelcontextprotocol/inspector#2458 · 1 comment ·
-
Difficulty 1/5 Under an hour Newbie friendliness 75/100
railmapgen/rmp-gallery#4068 ·
-
Mend: dependency security vulnerability status: needs triage 🕵️♀️
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
carbon-design-system/ibm-products#9907 ·