File extension specific settings

[esprehn]

This was discussed here:
#1587

but instead what was implemented was language specific settings. That doesn't help us where we have the same language in files with different extensions but what to impose different settings on them.

(ex. I have a DSL like language that looks like JS, I want to make it syntax highlight as JS, but disable validation because some things aren't quit right. Having to fork the JS language bindings for that and maintain it is unfortunate.)

[sandy081]

@esprehn You can associate file types with languages and associate settings to languages

Example:

"files.associations": {
	"*.idt": "markdown"
}
"[markdown]": {
          "editor.tabSize": 2
}

Is there a different use case that you need to associate settings to file associations?

[vscodebot]

This issue has been closed automatically because it needs more information and has not had recent activity. Please refer to our guidelines for filing issues. Thank you for your contributions.

[esprehn]

I explained why I need this in the report example. I have a DSL that looks like JS, but isn't quite JS. I can map files with extension .foo to JS, but I can't say "syntax highlight .foo files, but don't show syntax errors". I would need to totally disable syntax errors for all JS language files. Similarly I may want other editor settings different for .foo files (ex gutter width), but I do want them syntax highlighted like JS.

I often do this in other editors like Sublime where I have various languages that have no language definition mapped to another language (ex. some obscure language I might map to Java since they have the same keywords.) That way I get nice syntax highlighted code which is easier to read. VSCode forces you to set things like the syntax error (red underline) reporting for a whole language, not on a per extension basis.

[sandy081]

@esprehn I see. I agree with the editor settings example.

But for excluding files from linters, I think linters should have an option to exclude.

[esprehn]

Having those settings be on a per linter setting seems unfortunate, there's tons of settings like php.validate.enable, each type has a {lang}.validate.enable flag. Instead of having every linter support .exclude it'd be much easier to just allow "[.foo]": { "php.validate.enable": false }

[Kroc]

I don't like that unless the user has an extension installed to handle a file-type, I cannot specify the tab / ruler settings for arbitrary file-types in a portable, reliable way. For example, I have my own Markdown like system "ReMarkable" with a file-type of ".rem", it requires the use of tabs instead of spaces. I want to be able to specify this in the repositories I distribute, but with VSCode as it currently stands cannot do this.

".editorconfig" gets me almost there, but it's not a built in extension (it should be), and it doesn't support setting rulers.

Please reconsider this feature request.

[joemaffei]

I would like to see filename-specific settings. I happen to work in an environment that uses tabs, except for a few files like package.json that are indented with two spaces. I don't want an extension-specific or language-specific setting for json. "editor.detectIndentation": true does the trick if I edit an existing file, but obviously not when I create a new one. Being able to set indentation rules on a filename basis, as well as other settings like formatOnSave, etc, would be very helpful.

[aaronkahlhamer]

Here's my feeble attempt to stop it from formatting production files...

"editor.formatOnSave": true,
"files.associations": {
    "**/dist/**": "ignore"
  }

It works. Problem is, it converts it to Plain Text. I wish the following worked...

"[**/dist/]": {
   "editor.formatOnSave": false
}

[no-stack-dub-sack]

@mjbvz this discussion seems mostly central to file extension specific settings (except for @joemaffei's comment above), whereas #50888 & #52087 (closed as dupes) focus on individual files and directories - if this discussion is meant to encompass all three of these issues as one feature request now, can you consider renaming it so that others trying to open similar issues will be more easily able to identify this as a potential duplicate?

If this discussion will remain central to file extensions only, can one of the other issues be reconsidered as a separate feature request? Thank you!

[ma11hew28]

I want word wrap on for .txt files but not for .csv files.

[Srekel]

Just to add a use case: We format some of our our C++ headers manually but always use clang-format for source files, so I'd like to enable format-on-save just for "*.cpp" files.

[DanTup]

I wish the following worked...

"[**/dist/]": {
   "editor.formatOnSave": false
}

I'd like this too - is there any way to make this work today?

[aster94]

if editorConfig was bundled with VSCode this would be so easy (for the users), hope to see this achieved soon

"files.insertFinalNewline": false,
[keywords.txt]{
    "files.insertFinalNewline": true,
}

[kuzdogan]

I usually find myself jumping to types.d.ts file definitions when working on Typescript and fixing that file, only to compile and find out that nothing's changed and I didn't update the definition.

In my case I want to change the background of .d.ts pseudo extension to notice when I'm about to edit an already compiled file. Even better if I can set this setting to **/dist/*.d.ts or `**/build/*.d.ts/ etc.

For my use case I found this extension that does the job https://marketplace.visualstudio.com/items?itemName=rioj7.WhenFile but nice to have other VSCode settings per extension too

[mehulkar]

Another use case, I'm using Prysk to write tests. The file extension for test files is .t and I want to disable removing trailing white spaces on save for these files. I can assosicate these files with [plaintext], but that affects all plaintext files, which is not ideal.

In general, it should be possible to have settings for file extensions that are generally unknown to VSCode.

[KuSh]

Another use case, I'm using Prysk to write tests. The file extension for test files is .t and I want to disable removing trailing white spaces on save for these files. I can assosicate these files with [plaintext], but that affects all plaintext files, which is not ideal.

In general, it should be possible to have settings for file extensions that are generally unknown to VSCode.

You could use an editorconfig for that:

[*.t]
trim_trailing_whitespace = false

[mehulkar]

@KuSh I tried that, but it seems that VSCode settings are trumping editorconfig config.

[BillDenton]

For C/C++ files I'd like to enable format on save for some file paths. Some of the source files have been formatted (clang-format). I would like to keep those files formatted, but not touch other files.

[WillsterJohnson]

Is there any interest from the team to do anything about this?

It's been over three years since a member even commented on this #35350 (comment) and it's been over five years since a member made a comment actually about this issue #35350 (comment).

If you're not going to implement something, at least let us know with a wontfix or something rather than leaving the issue open for five and a half years with no word.

[shaneknysh]

I think it's pretty clear there is no interest from the team to address this. I'm not certain why it hasn't been closed other than so duplicates aren't created.

The options for a work around are not ideal either.

I also don't see this as the job of a plugin or a job a single plugin could do well.

[WillsterJohnson]

Honestly, I don't know why I keep being surprised at this sort of thing in Microsoft projects.
Someone suggests something cool, everyone who sees it loves it, permanent radio silence.

It's not all feature requests, not by a long shot, but enough requests are ignored that it's intensely uppsetting.

[shaneknysh]

It could be that the effort is too high and it benefits too few users.

[palapapa]

Still not supported after 6 years. Is it possible to make an extension that will allow applying arbitrary settings based on the current file extension instead of only the predefined "language-specific settings"?

[KieranP]

I too would find this useful. Our use case is as follows: We are redesigning our web application. In one folder we have all the old legacy CSS/JS, which doesn't conform to our new coding style/formatters. In another folder, we have all our new CSS/JS, which we want formatting to run on save for. We have turned on format on save for JS/CSS, but that means that now when we edit the old CSS/JS, it tries to format that, leading to lots of changes in the diff. Would be helpful to be able to turn off format on save for a path.

"[css][scss][javascript][typescript]": {
  "editor.defaultFormatter": "esbenp.prettier-vscode",
  "editor.formatOnSave": true
},
"[app/assets/**/*]": {
   "editor.formatOnSave": false
}

[shaneknysh]

Given that this is 6 years old now and the only response from anyone close to being on the vs code team has been:
"no one wants this" and
"use an extention"
I think it is probably safe to move on with the assumption it is never going to happen.

Gretchen Wieners will make "Fetch" happen faster than this will be addressed.

[gmusante]

👍

[Keavon]

Just throwing in my support for this since it hasn't had any activity in a couple months.

My use case: I use Prettier to format my regular JSON files, but I have another file type that stores a whole bunch of data in JSON format and I have "files.associations": { "*.my-file-extension": "json" } set up for syntax highlighting. There's a bug in the Prettier formatter which breaks the JSON in these files, so I want to use the "vscode.json-language-features" formatter for my custom data type. Right now it seems to be one or the other, I can't set Prettier for regular JSON and JSON Language Features for my custom file extension JSON file.

[aradalvand]

Almost 7 years since this issue was created and such a basic feature still hasn't been implemented. Why the hell are you not even reacting to an open issue with this many upvotes?!

Embarrassing. Absolutely shameful. You've proven yourselves to be outrageously irresponsible; congratulations.

[geekley]

not even reacting to an open issue with this many upvotes

I'd assume that on a repo with 5000+ open issues (probably the # 1 most issues in github), most/all devs have notifications disabled so they won't be overwhelmed with comments every second; thus I think they're only notified when specifically @ pinged.

[shaneknysh]

After 7 years not having notifications on is not an excuse for not addressing g this issue.

6 years ago we got a "use an extension" answer and a "won't fix" resolution. there is still not an extension that handles many of these use cases elegantly.

I messaged the vscode TikTok account and asked them to feature this issue in a video.

[starball5]

Related on Stack Overflow: vscode setting for specific filename

[ascpixi]

Joining in to show my support! This would be great for my build system, which uses Python-based build manifests. These files have some stuff pre-imported in, so it would be great if I could disable type checking just for those files.

I'm using "python.analysis.ignore": ["**/component.build"] for now, but it leaves a lot to be desired - it doesn't even highlight the most basic syntax errors. :(

[Frexuz]

my use case that doesn't work, is to support chained file extensions:

  "[html.erb]": {
    "editor.formatOnSave": true,
    "editor.defaultFormatter": "aliariff.vscode-erb-beautify"
  },

it seems it doesn't match the saved file... (im guessing it's only matching against the file's last .erb extension?)

i only want to beautify html templates with this plugin, but not other template files that also uses the erb engine (like server provisioning config templates)

[gjsjohnmurray]

@Frexuz this issue is asking for a new feature that doesn't yet exist even for simple (single dot) file extensions.

[CEbbinghaus]

Is this going to require another "[x, y, x]": treatment where someone just implements a naive version and the team steal it and make it work properly? I think that may be the fastest way to get it into main.

Haven't comprehensively checked all messages but I feel like the general want is for a globbing syntax to allow for overriding settings based on the file. Since a glob pattern might overlap with the language [markdown] syntax we may want to consider a different style. How about something like "(glob pattern)". And all it would require is a pure glob match against the currently open file within the editor and that should do it. Anybody got other considerations for the design or does that cover most use cases?

[Okladnoj]

My issue #232954 was closed referencing this topic. I partially agree, but there is one nuance I'd like to clarify:

It would be great to configure formatting rules not only by file extension but also by matching patterns in the file name using regular expressions. Something like **/*_model.dart (noting that this should apply within the scope of a single language).

I explain in more detail below why this is necessary in projects.

This feature would be especially useful for Dart and other languages where generated code, like constructors from packages like Freezed, becomes less readable with a standard line length of 80 characters. Being able to specify a longer line length (e.g., 200 characters) for these specific files would improve code readability without affecting the rest of the project.

Example of Desired Configuration:

"[dart]": {
  "editor.rulers": [80],
    "**/*_model.dart": {
    "editor.rulers": [200]
  }
}

Code Example Highlighting the Issue:

@immutable
@Freezed(makeCollectionsUnmodifiable: false)
class TransactionsRequestModel with _$TransactionsRequestModel {
  const TransactionsRequestModel._();

  @HiveType(typeId: HiveManager.idTransactionsRequestModel)
  const factory TransactionsRequestModel({
    @HiveField(0) @JsonKey(name: 'type') @Default(TransactionType.all) @TransactionTypeConverter() TransactionType type,
    @HiveField(1) @JsonKey(name: 'sort_by') @Default(SortFactorType.displayMostRecent) @SortFactorTypeConverter() SortFactorType sortFactor,
    @HiveField(2) @JsonKey(name: 'date_from') @DateConverter() DateTime? dateFrom,
    @HiveField(3) @JsonKey(name: 'date_to') @DateConverter() DateTime? dateTo,
    @HiveField(4) @JsonKey(name: 'search') @Default('') String search,
    @HiveField(5) @JsonKey(name: 'page') @Default(1) int page,
    @HiveField(6) @JsonKey(name: 'tags') @Default([]) @TagConverter() List<TagModel> tags,
    @HiveField(7) @JsonKey(name: 'category') int? categoryId,
  }) = _TransactionsRequestModel;

  factory TransactionsRequestModel.fromJson(Map<String, dynamic> json) =>
      _$TransactionsRequestModelFromJson(json);

  StatisticRequestModel get toStatistic {
    return StatisticRequestModel(
      type: type,
      dateTo: dateTo,
      dateFrom: dateFrom,
      search: search,
      tags: tags,
    );
  }
}

As shown above, setting the line length to 80 characters makes these constructors difficult to read and manage. A more flexible approach for file-specific formatting settings would greatly improve developer productivity and code clarity.