Summary

This is a PR that should be merged into #1024 and incrementally addresses #842.

This change extends the proposed ESLint config to allow for type properties in src/types/**/*.ts files to be named in snake_case. Of the 1342 linting problems still to resolve in #1024, 830 of them are for the @typescript-eslint/naming-contention rule (specifically: about renaming these properties to be camelCase), and this PR drops the number of problems from 1342 down to 745.

Here is an example of the naming-conventions rule failing without the changes in this pull request:

/Users/fmaj/src/bolt-js/src/types/view/index.ts
   41:5  error  Type Property name `enterprise_id` must match one of the following formats: camelCase           @typescript-eslint/naming-convention
   42:5  error  Type Property name `enterprise_name` must match one of the following formats: camelCase         @typescript-eslint/naming-convention

That said, even with enabling this rule, turns out some type properties under src/types then fail as we use camelCase for them 😄:

/Users/fmaj/src/bolt-js/src/types/middleware.ts
  43:3  error  Type Property name `botToken` must match one of the following formats: snake_case      @typescript-eslint/naming-convention
  48:3  error  Type Property name `userToken` must match one of the following formats: snake_case     @typescript-eslint/naming-convention
  54:3  error  Type Property name `botId` must match one of the following formats: snake_case         @typescript-eslint/naming-convention
  59:3  error  Type Property name `botUserId` must match one of the following formats: snake_case     @typescript-eslint/naming-convention
  63:3  error  Type Property name `teamId` must match one of the following formats: snake_case        @typescript-eslint/naming-convention
  67:3  error  Type Property name `enterpriseId` must match one of the following formats: snake_case  @typescript-eslint/naming-convention

What does the team think? Do we want to enforce naming conventions for src/types? I am coming at this task from a place of ignorance; I don't know how the source "should" look like, so this is an attempt at formalizing whatever style already exists in the project as the canonical ESLint style. If this is not the direction we want to go, cool - I am happy to tackle renaming the type properties. Consider this PR a place to discuss and debate 😄

Requirements (place an x in each [ ])

• I've read and understood the Contributing Guidelines and have done my best effort to follow them.
• I've read and agree to the Code of Conduct.