Skip to content

Simplifying configuration #7185

Open
Open
@SimenB

Description

@SimenB

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
  • 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.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions