Using a formatter for formatting (instead of lint rules)

[JoshuaKGoldberg]

Update (October 9th, 2023): This work is done! As of #66235's merge on October 6th, all DefinitelyTyped's types files are formatted with dprint (with a small number of temporary exceptions for build issues).

---

Context

👋 Hi all! I've been working with the TypeScript team on overhauling DefinitelyTyped's usage of formatting and linting tools. Alongside the effort to finally migrate from TSLint to ESLint (https://typescript-eslint.io/linting/troubleshooting/tslint -> microsoft/DefinitelyTyped-tools#648), we'd like to align with how much of the industry & many linter maintainers recommend using a formatter vs. a linter (myself included).

This is a surfacing of a plan we've formulated that we think will get DefinitelyTyped onto using a proper formatter for formatting. I'd very much like to see the community's reaction: does this seem reasonable to you? What edge cases are we missing? Will this offend your sensibilities as a programmer?

DefinitelyTyped's Formatting Context

DefinitelyTyped today only utilizes a few ESLint rules for code formatting. It does not use Prettier, dprint, or other dedicated formatting tools.

We'd like to move DefinitelyTyped onto one of those tools for the following benefits:

• Consistency: so contributors don't have to adjust to different formatting preferences per types package.
• Dev time: formatters save contributor time from being spent on manually touching up files.
• Diff sizes: so developers stop accidentally (or intentionally) reformatting entire files in the course of making an unrelated change.
• Easier TSLint to ESLint migration: removing usage of formatting rules reduces the amount of logic we'll need to port from TSLint to ESLint

✋ Please do not reply to this with formatting opinions.
We know using a formatter instead of a linter for formatting can be a contentious choice.
Bikeshedding on nuances of whitespace preferences is not useful.

The Plan

1. Determine the formatter choice and formatting configuration
2. Create and merge a DefinitelyTyped-tools pull request that removes all formatting rules
3. Simultaneously to (2), create and merge DefinitelyTyped pull requests that:
   • Runs the formatter on all files in DefinitelyTyped
   • Adds checking in formatting fixes to the merge bot
   • Adds a GitHub Action that makes a new commit to format all files if needed after merges to master
4. Create and merge a DefinitelyTyped pull request that adds a .git-blame-ignore-revs file to ignore the large formatting commits

Edit August 10th: @jakebailey, @sandersn, and I discussed the "check in formatting fixes to the merge bot" bit in more detail. It's a complicated work item given GitHub's security concerns & approval flows, and dprint performance has been consistently excellent. We're going to table it until it's shown to be needed (i.e. conflicts from master temporarily being unformatted start arising frequently).

Formatter Choice: dprint

The two most common standalone formatters in the JavaScript/TypeScript ecosystem today are:

• dprint: much faster, but less popular
• Prettier: more popular, but slower

We plan on using dprint for formatting for its superior performance.

A quick comparison of running both tools and pprettier on DefinitelyTyped shows a 10 second vs. minutes-scale difference:

npx dprint fmt  141.52s user 9.29s system 1481% cpu 10.177 total
npx pprettier --write './types/**/*.{ts,mts,cts}'  8.97s user 3.18s system 21% cpu 56.725 total
npx prettier -w ./types  361.28s user 35.60s system 126% cpu 5:13.36 total

dprint is also able to use a cacheable file cache, which drops times down to under a second. We may look into using it in CI as a followup performance optimization.

Additionally, running dprint on as large a repository as DefinitelyTyped will provide it and SWC with helpful community dogfooding (e.g. swc-project/swc#7187, dprint/dprint-plugin-typescript#533). Note that dprint is essentially deno fmt, so we're not worried about its ability to handle all of DefinitelyTyped.

Formatting Configuration

DefinitelyTyped today already has a .prettierrc.json Prettier configuration file:

{
  "$schema": "http://json.schemastore.org/prettierrc",
  // Edit August 29th: Removed overrides. See below.
  // "arrowParens": "avoid",
  // "singleQuote": true,
  // "trailingComma": "onlyMultiLine",
  "tabWidth": 4,
  "printWidth": 120
}

Our plan is to use the closest equivalent dprint TypeScript configuration. This proposal does not include work to change those settings. No set of settings is perfect or will satisfy all users.

Edit August 29th: Following #66238 (comment) & #66238 (comment), I removed the style overrides.

FAQs

Explainer: When Formatting Runs

Pull request CI builds will not be blocked on formatting, so as to not inconvenience contributors who don't run a formatter. However, two parts of the plan ensure the master branch stays fully formatted the master branch will be fully formatted most of the time:

• Most PRs are merged by the DT bot: which can apply apply formatting on each PR as part of its existing merge process.
• For manual merges done by maintainers: the action that runs on merges to master will capture any formatting mishaps The action that runs after merges to master will quickly format it if needed.

Edit August 10th: see earlier note on tabling mergebot changes.

As a follow-up, we may want to create a general-purpose PR bot to make it easier for contributors to apply formatting to a PR on their behalf. This is out of scope for the current proposal.

Can Files Opt Out of Formatting?

Yes, but considering the advantages mentioned earlier in this proposal, we strongly advise against doing so. Individual files that are auto-generated can use configuration file excludes and/or // dprint-ignore-file file ignore comments to disable the formatter.

Edit July 31st, 2023: As of dprint/dprint#719, dprint also supports nested configurations. Individual types/ directories can reconfigure dprint if they absolutely need. We'll set this up for directories that are fully auto-generated.

Is Formatting Performance Important?

Most users would not notice a difference in performance between dprint and Prettier, as most files aren't large enough (thousands of lines long) to cause a significant difference. However, the CI runs on the master branch should ideally be as fast as possible to minimize the chance of users branching off a master commit with incorrectly unformatted code.

Tabs or Spaces?

One potential side effect of switching to a dedicated formatter is that individual projects that prefer using tabs for accessibility may find it harder to do so in the project. We'll seed the configuration file to disable formatting for existing packages that use tabs. Please let us know if that's not enough: we can try to brainstorm a workaround, such as adding the ability to have project-specific overrides to the formatter.

Edit July 31st, 2023: As of dprint/dprint#719, dprint also supports nested configurations. Individual types/ directories can reconfigure dprint if they prefer need. Our initial PR that converts DefinitelyTyped to dprint will use tabs in all packages that seem to prefer them.

Today, only 19 packages use tabs - as determined by finding all types/ directories that have any file with a number of \n\ts greater than 1% of its total \n count. Therefore, this proposal is not changing how the vast majority (>99.9%) of types packages use spaces. Doing so is a potential large follow-up task we can look into.

Script run to find types packages that use tabs

import fs from 'node:fs/promises';
import path from 'node:path';

async function checkDirectoryPathForTabs(directoryPath) {
    const directoryItems = await readdirSafe(directoryPath);

    for (const directoryItem of directoryItems ?? []) {
        const directoryItemPath = path.join(directoryPath, directoryItem);
        if (!directoryItemPath.includes('.ts')) {
            continue;
        }

        const contents = await readFileSafe(directoryItemPath);
        if (!contents) {
            continue;
        }

        const newlineTabsCount = contents.match(/\n\t/g)?.length ?? 0;
        if (!newlineTabsCount) {
            continue;
        }

        const newlineCount = contents.match(/\n/g)?.length ?? 0;

        if (newlineTabsCount > newlineCount / 100) {
            console.log(directoryPath)
            return;
        }
    }
}

async function readdirSafe(dirPath) {
    try {
        return await fs.readdir(dirPath);
    } catch {
        return undefined;
    }
}

async function readFileSafe(filePath) {
    try {
        return (await fs.readFile(filePath)).toString();
    } catch {
        return undefined;
    }
}

for (const directory of await fs.readdir('./types')) {
    const directoryPath = path.join('./types', directory);

    await checkDirectoryPathForTabs(directoryPath)
}

Package names logged by that script

types/anime-quotes-api
types/arcgis-js-api
types/bootbox
types/ceddl__ceddl-polyfill
types/classificator
types/dns-packet
types/do-not-zip
types/ej.web.all
types/gulp-help
types/gulp-inject
types/js2coffee
types/json-query
types/qbittorrent-api-v2
types/react-leaflet-markercluster
types/reefjs
types/steelseries
types/titanium
types/uuid4
types/vscode

What About .json and .md Files?

(added July 31st 2023)

This proposal doesn't intend to format those files with the formatter. We may look into that as a followup.

What's the Difference Between a Formatter and a Linter?

A formatter quickly (re-)formats code without adjusting any code logic. A linter runs a set of discrete rules that each flag -and optionally suggest fixes- for a specific kind of code defect.

See https://github.com/readme/guides/formatters-linters-compilers for more context.

Why split up the PRs so much?

Splitting up changes is easier on tooling:

• It's easier to review the diffs on github.com (the Files view slows down at hundreds of files)
• Blocking CI failures for a package will only block that package's PR
  • Example difficulty: header-parser should mention which file failed to parse microsoft/DefinitelyTyped-tools#719
• If we need to revert later on, we'll be able to do so more granularly

Our splitting strategy was:

1. Find the biggest packages (Using a formatter for formatting (instead of lint rules) #65993 (comment)) and send their PRs early
2. Then, send a PR for each letter of the alphabet
   • This is arbitrary but makes it easier to associate PRs with their related packages

Thanks

This proposal came out of a group thread with discussion from:

• David Sherret
• Jake Bailey
• John Reilly
• Josh Goldberg
• Nathan Shively-Sanders
• Piotr Błażejewicz
• Sebastian Silbermann

Appreciation in particular to Jake Bailey and Nathan Shively-Sanders for advising from the TypeScript team, and David Sherret from dprint.

[bradzacher]

A few quick points re prettier v dprint from experience.

Dprint is nowhere near as strict as prettier is - it allows a lot of variations in formatting an expression statement.
Depending on what you're trying to enforce - this may or may not be a factor. Given you're migrating from formatting lint rules (which from my experience are even less strict) - I doubt that it matters too much.

In regards to DevX - it's highly unlikely contributors have the dprint extension installed - meaning they won't get format on save and will have to rely on CLI formatting instead. Not a massive deal but it is something to consider. OTOH a contributor is much more likely to have the prettier extension installed.

In regards to performance - a lot of people tout runtime performance as a big negative for prettier. However one big counter point to this is that if you're doing things correctly then you should only ever be running your formatter in O(changeset), not O(repo). For most changes this should make for a fraction of the scale and thus a fraction of a runtime - to the point that the two tools are the same.

For some context I've spent a lot of time working with prettier at scale (I did several prettier version bumps on Meta's >800k file megarepo) and perf wasn't ever an issue. It does suck the few times you need to do an O(monorepo) run - but these should be rare times.

---

That aside - really happy to see this.

Moving off of TSLint will be huge in of itself - and having formatter for the codebase will be great for keeping changes down (I've seen many people tweak indentation and destroy diffs!)

[JoshuaKGoldberg]

Status update (July 31st 2023): we've received only positive feedback on this proposal. So we're going to go for it. 🚀

On the dprint side, @dsherret added nested configuration support (👏 thank you!) in dprint/dprint#719. That means we can specify using tabs in existing types/ directories that prefer them (instead of disabling dprint in them altogether). I've updated the suggestion with an explicit edit note.

My plan now is to:

1. Work on creating a PoC PR for this repository per step 3
   • Note that it might be split up into multiple PRs to help with reviewing
2. Once that PR is / those PRs are ready for review, creating a DefinitelyTyped-tools PR per step 2
3. Run all those PRs through review and broadcasting them on social media for visibility
4. Once those PRs are merged, continue to step 4

Note that we've only received explicit feedback from a couple dozen individuals. That's a relatively small fraction of even the active pool of DefinitelyTyped contributors. I'll be sure to include "please give feedback even at this stage in the process" notes in all messaging to make it clear that we do still want feedback.

[jakebailey]

@cferdinandi You are listed as a maintainer of @types/reefjs and that also means you'd get pinged on PRs, discussions about it, etc, and this change would affect @types/reefjs.

If you aren't reviewing / maintaining these types, then we can drop the comment from the d.ts file to remove you from getting pinged; the types don't appear to have been updated in 2 years, it seems (and are still at v7.6, many many versions behind), which is probably why you hadn't noticed! 😄

[cferdinandi]

Yea, someone else definitely created that and submitted it on my behalf, because it wasn't me. Don't use Typescript!

[Rick-Kirkham]

@JoshuaKGoldberg We actually have 3 type definition folders in DefinitelyTyped. Besides the office-js that you noted, there's office-js-preview and office-runtime.

You are correct that our *.d.ts files are partially autogenerated and partially manually written.

We'd like you to configure (or tell us how to configure) things so that dprint doesn't run at all in our 3 libraries. The primary reason is that, in addition to being a source Intellisense, our *d.ts files are one of multiple inputs to a complex system of generating reference documentation for our APIs. We don't want to risk that changes in the formatting of the *.d.ts files will break that system, or produce formatting in the documentation that is inconsistent with the formatting of other inputs into the system (such as a set of example code snippets that we maintain locally).

In light of the nesting support in the latest dprint, I'll make a work item for us to install dprint locally and do some experiments with its configuration. If we find a pattern that works for us, we'll get back to you. But we are understaffed, so it may be many months before we have a chance to do that.

[JoshuaKGoldberg]

Great, thanks for the info @Rick-Kirkham! We'll add all three of those packages to the "excludes" section of dprint.json. They won't have formatting run on them at all.

[Rick-Kirkham]

@JoshuaKGoldberg We have one more that I didn't know about: custom-functions-runtime.

[JoshuaKGoldberg]

Here's a list of relevant issues and pull requests:

DefinitelyTyped:

• Added dprint config and commit-on-master task #66235
• chore: removed remaining formatting lint rules #66522
• Letters of the alphabet:
  • Formatted types/a* packages with dprint #66238
  • Formatted types/b* packages with dprint #66523
  • Formatted types/c* packages with dprint #66524
  • Formatted types/d* packages with dprint #66525
  • Formatted types/e* packages with dprint #66526
  • Formatted types/f* packages with dprint #66527
  • Formatted types/g* packages with dprint #66528
  • Formatted types/h* packages with dprint #66529
  • Formatted types/i* packages with dprint #66530
  • Formatted types/j* packages with dprint #66531
  • Formatted types/k* packages with dprint #66532
  • Formatted types/l* packages with dprint #66533
  • Formatted types/m* packages with dprint #66534
  • Formatted types/n* packages with dprint #66535
  • Formatted types/o* packages with dprint #66536
  • Formatted types/p* packages with dprint #66537
  • Formatted types/q* packages with dprint #66538
  • Formatted types/r* packages with dprint #66539
  • Formatted types/s* packages with dprint #66540
  • Formatted types/t* packages with dprint #66541
  • Formatted types/u* packages with dprint #66542
  • Formatted types/v* packages with dprint #66543
  • Formatted types/w* packages with dprint #66544
  • Formatted types/x* packages with dprint #66545
  • Formatted types/y* packages with dprint #66546
  • Formatted types/z* packages with dprint #66552
• Individual or smaller groups of packages:
  • [arcgis-js-api] ran dprint fmt #66359
  • [aws-sdk2-types] ran dprint fmt #66360
  • [carbon__icons-react] ran dprint fmt #66361
  • [carbon__pictograms-react] ran dprint fmt #66362
  • [consumer-data-standards] ran dprint fmt #66363
  • [docusign-esign] ran dprint fmt #66358
  • [ej.web.all] ran dprint fmt #66357
  • [google-apps-script] ran dprint fmt #66356
  • [lodash-es] ran dprint fmt #66355
  • [microsoft-graph] ran dprint fmt #66354
  • [ramda] ran dprint fmt #66353
  • [react] ran dprint fmt #66352
  • [react-native] ran dprint fmt #66351
  • [selenium-webdriver] ran dprint fmt #66350
  • [titanium] ran dprint fmt #66349
  • Formatted types/(i18n|inquirer)* packages with dprint #66832
  • Formatted mp4frag with dprint and removed node/buffer import #66834
  • Formatted r* packages displaying CI issues with dprint #66850
  • Formatted non-letter and recently changed types with dprint #66858

DefinitelyTyped-tools:

• Allow dprint.json in definition-parser microsoft/DefinitelyTyped-tools#698
• feat: remove formatting rules rules from dtslint microsoft/DefinitelyTyped-tools#699
• feat: add descriptor to header-parser parseHeaderOrFail errors microsoft/DefinitelyTyped-tools#720
• feat: remove comment-space from dtslint.json too microsoft/DefinitelyTyped-tools#721
• fix: set comment-format to false, explicitly microsoft/DefinitelyTyped-tools#722
• feat: explicitly disabled more formatting rules and removed trim-file microsoft/DefinitelyTyped-tools#723
• fix(eslint-plugin): [no-self-import] account for nested ('grandparent') path names microsoft/DefinitelyTyped-tools#726
• feat: mention which index.d.ts in definition-parser microsoft/DefinitelyTyped-tools#728

I'll keep it updated over time.

[JoshuaKGoldberg]

I did some shell scripting to find the biggest packages on DT. Running on macOS after removing all node_modules with rm -rf node_modules types/*/node_modules types/*/*/node_modules (+ a few more levels of */* just in case)...

Directories >1M

du -sh types/* | grep M | sort -nr

 25M    types/dojo
 17M    types/carbon__icons-react
 16M    types/node
 15M    types/openui5
 14M    types/devexpress-web
 13M    types/echarts
8.5M    types/fhir
8.2M    types/carbon__pictograms-react
6.4M    types/arcgis-js-api
5.2M    types/office-js-preview
5.1M    types/react-native
5.1M    types/activex-libreoffice
5.0M    types/office-js
4.9M    types/winrt-uwp
4.7M    types/lodash
4.1M    types/ignite-ui
3.4M    types/three
3.0M    types/ramda
2.9M    types/es-abstract
2.8M    types/ej.web.all
2.4M    types/extjs
2.3M    types/aws-sdk2-types
2.2M    types/sencha_touch
2.1M    types/jquery
2.0M    types/facebook-nodejs-business-sdk
1.9M    types/nginstack__engine
1.9M    types/docusign-esign
1.8M    types/hapi
1.8M    types/google-apps-script
1.7M    types/titanium
1.4M    types/react
1.4M    types/openfin
1.4M    types/activex-mshtml
1.3M    types/microsoft-graph
1.3M    types/lodash-es
1.3M    types/carbon-components-react
1.1M    types/winjs
1.1M    types/wechat-miniprogram
1.1M    types/p5
1.1M    types/openlayers
1.1M    types/fibjs
1.1M    types/consumer-data-standards
1.0M    types/selenium-webdriver
1.0M    types/crocks

Files >1M

find types ~+ -type f | xargs du -sh | sort -nr

5.5M    types/arcgis-js-api/index.d.ts
5.2M    types/office-js-preview/index.d.ts
5.2M    types/dojo/dijit.d.ts
5.0M    types/activex-libreoffice/index.d.ts
4.9M    types/winrt-uwp/index.d.ts
4.9M    types/openui5/sap.m.d.ts
4.9M    types/office-js/index.d.ts
4.1M    types/ignite-ui/index.d.ts
3.0M    types/dojo/dojox.mobile.d.ts
2.9M    types/openui5/sap.ui.core.d.ts
2.4M    types/extjs/index.d.ts
2.2M    types/ej.web.all/index.d.ts
2.1M    types/sencha_touch/index.d.ts
1.9M    types/docusign-esign/index.d.ts
1.8M    types/fhir/r5.d.ts
1.7M    types/titanium/index.d.ts
1.6M    types/devexpress-web/v182/index.d.ts
1.6M    types/devexpress-web/v181/index.d.ts
1.5M    types/dojo/dojox.widget.d.ts
1.5M    types/devexpress-web/v172/index.d.ts
1.5M    types/devexpress-web/index.d.ts
1.4M    types/openui5/sap.ui.webc.main.d.ts
1.4M    types/dojo/index.d.ts
1.4M    types/dojo/dojox.form.d.ts
1.4M    types/devexpress-web/v201/index.d.ts
1.4M    types/devexpress-web/v192/index.d.ts
1.4M    types/devexpress-web/v191/index.d.ts
1.4M    types/devexpress-web/v171/index.d.ts
1.4M    types/activex-mshtml/index.d.ts
1.3M    types/microsoft-graph/index.d.ts
1.3M    types/fhir/r4b.d.ts
1.3M    types/fhir/r4.d.ts
1.2M    types/dojo/dojox.dgauges.d.ts
1.2M    types/devexpress-web/v162/index.d.ts
1.1M    types/dojo/dojox.mvc.d.ts
1.1M    types/dojo/dojox.grid.d.ts
1.1M    types/dojo/dojox.gauges.d.ts
1.1M    types/devexpress-web/v161/index.d.ts
1.0M    types/echarts/options/series/graph.d.ts
1.0M    types/dojo/dojox.calendar.d.ts

.md files with the text generate

grep  -e "generate" --include=\*.md -lnrw types

types/lodash/readme.md
types/simperium/README.md
types/meteor/globals/README.md
types/meteor/test/globals/README.md
types/meteor/README.md
types/material-ui/scripts/README.md
types/dojo/README.md
types/sawtooth-sdk/README.md
types/node/ts4.8/scripts/generate-inspector/README.md
types/node/ts4.8/scripts/generate-docs/README.md
types/node/scripts/generate-inspector/README.md
types/node/scripts/generate-docs/README.md
types/recharts/README.md

All the types/* folders referenced previously, as well as a couple of more that include a scripts/ directory

types/activex-libreoffice
types/activex-mshtml
types/arcgis-js-api
types/aws-sdk2-types
types/carbon__icons-react
types/carbon__pictograms-react
types/carbon-components-react
types/consumer-data-standards
types/crocks
types/devexpress-web
types/docusign-esign
types/dojo
types/echarts
types/ej.web.all
types/es-abstract
types/extjs
types/facebook-nodejs-business-sdk
types/fhir
types/fibjs
types/get-intrinsic
types/google-apps-script
types/hapi
types/ignite-ui
types/jquery
types/locutus
types/lodash
types/lodash-es
types/material-ui
types/meteor
types/microsoft-graph
types/nginstack__engine
types/node
types/office-js
types/office-js-preview
types/oibackoff
types/openfin
types/openlayers
types/openui5
types/p5
types/ramda
types/react
types/react-native
types/recharts
types/sawtooth-sdk
types/selenium-webdriver
types/sencha_touch
types/simperium
types/three
types/titanium
types/wechat-miniprogram
types/winjs
types/winrt-uwp

At the very least, we can check if they're auto-generated, and exclude them from dprint if so.

[JoshuaKGoldberg]

I went through those lists of packages and this seems to be the list of auto-generated ones:

types/custom-functions-runtime
types/dojo
types/facebook-nodejs-business-sdk
types/fhir
types/fibjs
types/get-intrinsic
types/locutus
types/lodash
types/material-ui
types/meteor
types/nginstack__engine
types/node
types/office-js-preview
types/office-js
types/office-runtime
types/oibackoff
types/oibackoff
types/openui5
types/p5
types/sawtooth-sdk
types/three
types/winrt-uwp
types/vscode

For each potential types package, I looked at whether it...

• ...explicitly mentioned being auto-generated
• ...has a sibling generation script file
• ...mentions being auto-generated in a README.md file
• ...has been updated in the last year
• ...has recent commits/PRs that seem to be manually authored

Edit: for the above seemingly auto-generated packages, these ones seem to have been updated recently (within the last year, by someone outside of the DT team):

custom-functions-runtime
facebook-nodejs-business-sdk
fhir
get-intrinsic
lodash
meteor
nginstack__engine
office-js-preview
office-js
office-runtime
openui5
p5
sawtooth-sdk
three
winrt-uwp
vscode

...while these were not updated recently by that definition:

dojo
fibjs
locutus
material-ui
oibackoff
sawtooth-sdk
winrt-uwp

---

The large packages that we aren't considering auto-generated (until & unless we're told otherwise) are:

types/activex-libreoffice
types/activex-mshtml
types/arcgis-js-api
types/aws-sdk2-types
types/carbon__icons-react
types/carbon__pictograms-react
types/carbon-components-react
types/consumer-data-standards
types/crocks
types/devexpress-web
types/docusign-esign
types/echarts
types/ej.web.all
types/es-abstract
types/extjs
types/google-apps-script
types/hapi
types/ignite-ui
types/jquery
types/lodash-es
types/microsoft-graph
types/openfin
types/openlayers
types/ramda
types/react
types/react-native
types/selenium-webdriver
types/sencha_touch
types/titanium
types/wechat-miniprogram
types/winjs

Edit: for the above seemingly manually authored packages, these ones seem to have been updated recently (within the last year, by someone outside of the DT team):

arcgis-js-api
aws-sdk2-types
carbon__icons-react
carbon__pictograms-react
consumer-data-standards
docusign-esign
ej.web.all
google-apps-script
lodash-es
microsoft-graph
ramda
react
react-native
selenium-webdriver
titanium

...while these were not updated recently by that definition:

activex-libreoffice
activex-mshtml
carbon-components-react
crocks
devexpress-web
echarts
es-abstract
extjs
hapi
ignite-ui
jquery
openfin
openlayers
sencha_touch
wechat-miniprogram
winjs

[bradzacher]

I'm not quite sure why it matters that it's aito-generated. They don't do any signed sourcs validation which means there's no reason that you can't run dprint over the code after generation so that it matches the codebase standard.

[JoshuaKGoldberg]

If we format for them on master, then every time they send a PR with updates, it'll be filled with irrelevant noise from formatting differences.

[bradzacher]

I'm not sure I understand - why couldn't they just run the formatter themselves afterwards?

1. generate types
2. run formatter
3. submit PR

If they don't want to do (2) then that's up to them to deal with the noise in the review, IMO.

[JoshuaKGoldberg]

They could, but we've been trying to minimize the impact of this change. At least one of the partner teams have explicitly indicated they don't have budget to update their side.

My bet is that we'll have 1-2 dozen entries in the "excludes", then over the next few months we'll be able to trim it down to near-zero.

[JoshuaKGoldberg]

Now that folks have started talking about formatting preferences (#65993 (reply in thread) onward, #66238 (comment)), here's a comparison of how different overrides in #66235's dprint.json file (corresponding to overrides in the .prettierrc.json impact the Git diff. Before all this, I ran rm -rf types/*/node_modules; rm -rf types/**/node_modules.

$ find types | grep .d.ts | wc -l
29104
$ npx dprint --version
dprint 0.40.1
$ git diff --shortstat
25100 files changed, 1829028 insertions(+), 1653017 deletions(-)

Before each alternative, I ran git restore ..

Setting	Baseline	Alternative	Files	Insertions	Deletions	Δ Files	Δ Insertions	Δ Deletions
"*.useParentheses"	"preferNone"	"force"	25627	1835941	1659872	🔺 +527 (+2%)	🔺 +6,913 (+0.38%)	🔺 +6,855 (+0.37%)
"quoteStyle"	"alwaysSingle"	"alwaysDouble"	24805	1961398	1785401	🟢 -295 (-1%)	🔺 +132,370 (+7%)	🔺 +132,384 (+7%)
"trailingCommas"	"onlyMultiLine"	"never"	26754	1850403	1674797	🔺 +1,654 (-7%)	🔺 +21,375 (-1%)	🔺 +21,780 (-1%)

Fewer changes is considered better. 🟢 indicates fewer changes in an alternative. 🔺 indicates more changes in an alternative.

@dsherret, @jakebailey, and @sandersn have all privately mentioned a desire to switch to double quotes. We could certainly do that. edit: emphasis on the "could", as in this is a theoretical possibility

[jakebailey]

Maybe I'm brainfarting, but I'm having trouble understanding this table. Is the green dot saying that choosing alwaysDouble will result in fewer changes?

[JoshuaKGoldberg]

Correct - and I've edited in a note saying that explicitly.

[JoshuaKGoldberg]

Following up: I removed the TypeScript-specific overrides from the .dprint.jsonc in #66235. We want to start anew with the defaults, and didn't see any strong motivation from any partner teams or existing code to stick with previous overrides.

[icholy]

This is a great idea. Some suggestions:

• use .git-blame-ignore-rev
• disable typescript-bot for these PRs.