Simplifying configuration

This is a bit rambling, sorry about that. Feel free to edit this to clean it up and add more to it.

Jest currently has 51(!!) configuration options, many of which overlaps or intentionally overrides other options. (CLI options are out of scope for this issue, but they are obviously very much related)

They fall into a few different categories:

• file matching
  • some are arrays, some are not.
  • some are globs, some are regexes
    • collectCoverageFrom
    • coveragePathIgnorePatterns
    • forceCoverageMatch
    • modulePathIgnorePatterns
    • testMatch
    • testPathIgnorePatterns
    • testRegex
    • transformIgnorePatterns
    • unmockedModulePathPatterns
    • watchPathIgnorePatterns
• modules and mocking
  • confusing overlap with node’s require api (node paths, extensions)
    • resetMocks vs clearMocks vs restoreMocks
    • automock
    • moduleDirectories vs modulePaths (I honestly have no idea)
• Coverage things
  • reporters
  • thresholds
  • output directory
• Setup files
  • confusingly named, and inconsistent if they take array or string (#7119)
• it keeps going (feel free to edit)

---

First of all, I’d like to simplify the file matching a lot. Both to make it easier to use, but also easier to implement and reason about.

For file matching I think coveragePatterns: Array<Glob>, testPatterns: Array<Glob>, transformPatterns: Array<Glob> and remove everything else. You can use negated patterns to exclude things instead of a ignore thing. No more force to override ignores.

We could also group things (using the current names, although they are subject to change):

• coverage can have collectCoverage, coverageDirectory, coverageReporters, coverageThresholds, collectCoverageFrom
• setup can have globalSetup, setupTestFrameworkScriptFile, setupFiles, globalTeardown.
  • @palmerj3 had a cool idea about having just a single setup which exported different functions. Not as declarative, but maybe better?
• module can have automock, resolver, moduleDirectories, modulePaths, moduleNameMapper, moduleFileExtensions, resetModules
• mocks can have resetMocks, clearMocks, restoreMocks, timers (automock?`)
• snapshots can have snapshotSerializers, snapshotResolver
• notify and notifyMode can be combined (true is default mode, string sets the mode)

Another thing that’s somewhat confusing is the difference between ProjectConfig and GlobalConfig. While the separation makes sense, it’s invisible to users, and hard for them to reason about. It also doesn’t work well with presets.

---

Finally, I leave you with this awesome article https://fishshell.com/docs/current/design.html 🙂

Every configuration option in a program is a place where the program is too stupid to figure out for itself what the user really wants, and should be considered a failure of both the program and the programmer who implemented it.

[dandv]

On globs vs. regexp: I’ve been repeatedly confused by the patterns in test* options, and so have others. Turned out we didn’t know about micromatch. One way to eliminate the confusion would be to have options names specifically with a RegExp or Glob suffix.

On simplifying configurations: any thoughts on cascading/extending/inheriting hierarchical config files? Here’s a StackOverflow post requesting this feature.

I think ESLint does a great job at this with cascading configurations. It’s been very easy to use in monorepos: have an .eslintrc in the monorepo root with rules common to all projects, then in individual projects that need something different (e.g. env: { browser: false, node: true } vs. the other way around), only add those rules to a project-level .eslintrc. I’ve ❤️ed this setup for a long while.

[kentcdodds]

This is absolutely stupendous. Thank you all for your work here! It’s long been a point of confusion for me.