Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Mechanism for passing arbitrary extra config to formatters

Open
#66 3 comments 3 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Stale
Tech stack
vim
Domain
tooling

Research direction

The issue names .clang-format and .editorconfig as possible project-local configuration sources and cites js-beautify's --type and --aosp as examples. First map how formatter-specific options are currently selected; done means a decided, per-formatter and per-path mechanism that avoids conflicting defaults and unintended propagation.

Written by the indexing model from the issue text.

Description

enhancement

Lots of formatters have extra config users may want to pass, and creating a top-level flag for each one will get cumbersome. We should consider a generic mechanism for passing flags through to formatters.

Factors to consider:

  • These should be attached to the fine-grained formatter name, not the language, because we don't want to accidentally pass them to a different formatter that doesn't support them when the user switches formatter.
  • Some might conflict with default flags. For instance, a user might want to pass --type to js-beautify and find that it conflicts with the --type flag we already pass by default.
  • Most config would be per-path rather than global preferences. For instance, a user will want to configure an --aosp flag when working on Android Java, but then be surprised if it's applied to other Java code they're working on later.
  • If possible, these config options should live in some project-local config file like .clang-format or .editorconfig, not something codefmt-specific, and codefmt should just try to be smart about detecting and not conflicting with such config where appropriate.
Dominant language
Vim Script
Stars
1.1k
Forks
102
PR merge metrics
No merged PRs in 30d

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from google/vim-codefmt

All issues in google/vim-codefmt

Similar issues

More DevTools issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.