Expose jest configuration file on project generation

[C-Higgins]

Current Behavior

The default jest configuration is generated by a function at test runtime, and the user can specify an override, which is merged into the hidden default config

Suggested Solution

The jest configuration should just be generated into the root of the project. Probably the eslint config as well, but that doesn't have functionality issues like this one (see below).

Who does this impact? Who is this for?

Requiring merging configs has no benefits to the developer. If you ever need to change something, it usually results in having to write convoluted nested spreads, or pushing onto internal arrays of things. It's very confusing to understand what the final config is when this happens. If the user doesn't need to modify the config, the presence of the file does him no harm. The downside is that tsdx cannot update default options in existing projects, but a jest config is much less complex than something like a webpack config where that would be a major downside.

The larger reason this is useful is because IDEs such as Webstorm read the config file to understand how to run the IDE jest tooling. With the current configuration, Jetbrains IDEs cannot run the tests of tsdx projects because it doesn't know about the transforms option and so won't use ts-jest when necessary. If this feature will not be considered, consider instead exposing the jest config as a file and referencing it inside createJestConfig, so that people can at least point to the file inside node_modules.

Additional context

For anyone searching for this issue, to fix it you must define jest.config.js file with this in it:

module.exports = {
  transform: {
    '.(ts|tsx)$': require.resolve('ts-jest/dist'),
    '.(js|jsx)$': require.resolve('babel-jest'), // jest's default
  },
};

You then must also add ts-jest and babel-jest to your package.json and tell Webstorm to use that config file in your run configurations, if it does not use it by default.

[agilgur5]

Yes, this is a well-known issue and duplicates a handful of existing issues: outputting a Jest config is the topic of #270 (also #118) , IDE usage, VSCode to be specific, is the topic of #577 (and #439), and using presets instead of merging is the topic of #634 .

I didn't design the current system of merging; it indeed causes lots of problems. Particularly it's hard to override the defaults and it causes inconsistencies with tooling like IDEs for testing, linting, etc. That is why I'd like to switch to using explicit presets for all configs instead.
It's unfortunately a very breaking change and I've also been stuck on some Babel issues in #383 (comment) . Will probably have to put off that issue (which means adding one more breaking change and keeping an inconsistency) and a Babel preset for a bit while implementing the much simpler Jest and ESLint presets, but this won't be occurring in the short-term due to the breaking nature.

Probably the eslint config as well, but that doesn't have functionality issues like this one (see below).

The ESLint config has a variety of functionality issues as well, and I would say they're actually worse, c.f. #514 / #498