[feat] Add an option to save the generated jest.config.js

[lookfirst]

I want to be able to run jest tests from within my IDE (IDEA). It is far easier to just run jest directly than through tsdx test.

What I did was hacked a console.log() into node_modules/tsdx/lib/index.js, output the generated jest config and saved that in a jest.config.js file. Had to edit it a bit to remove the absolute paths (🤷‍♂ why those are there), but it works perfectly.

So, it would be nice to have something like the eslintconfig save option, but for the jest config.

[lookfirst]

I was just thinking further. Why not just generate a jest.config.js when creating the project?

Is there a good reason why tsdx test exists?

[jimmyn]

@lookfirst I totally agree. I'm working in WebStorm and it has good integration with Jest but it will only work with jest.config.js present because otherwise, typescript will not compile during tests.

I ended up creating jest.config.js with

const {createJestConfig} = require('tsdx/dist/createJestConfig');
const {paths} = require('tsdx/dist/constants');

process.env.BABEL_ENV = 'test';
process.env.NODE_ENV = 'test';

module.exports = createJestConfig(undefined, paths.appRoot);

It works although it's far from ideal solution as createJestConfig checks if jest.config.js file is present and might create a recursive loop

It would be awesome to add similar functionality to yarn lint --write-file

[lookfirst]

Sorry to be an ass and not share... here is what I'm using...

jest.config.js:

module.exports = {
  transform: {
    '.(ts|tsx)': 'ts-jest'
  },
  transformIgnorePatterns: [ '[/\\\\]node_modules[/\\\\].+\\.(js|jsx)$' ],
  moduleFileExtensions: [ 'ts', 'tsx', 'js', 'jsx', 'json', 'node' ],
  collectCoverageFrom: [ 'src/**/*.{ts,tsx}' ],
  testMatch: [ '<rootDir>/**/*.(spec|test).{ts,tsx}' ],
  rootDir: '.',
  setupFilesAfterEnv: ['./jest.setup.js'],
};

jest.setup.js:

global.window = {};
window.scroll = function () {
};
window.__DEV__ = true;

// even with latest react, still running into this on a couple of tests where i could not wrap
// things into an async act. maybe some day this will get fixed, but right now it is just an
// annoying useless warning.
const consoleError = console.error;
beforeAll(() => {
	jest.spyOn(console, 'error').mockImplementation((...args) => {
		if (!args[0].includes('Warning: An update to %s inside a test was not wrapped in act')) {
			consoleError(...args);
		}
	});
});

[jaredpalmer]

Yes, tsdx test makes sense so we can
upgrade jest for all of our users

[lookfirst]

Yes, tsdx test makes sense so we can upgrade jest for all of our users

That answer doesn't make much sense to me because:

1. The way tests were run was recently changed, which was a breaking change to go from non-watch to watch. I had to lookup the documentation, which was a tad bit frustrating. In other words, the upgrade path here isn't always clear.
2. We are talking about the difference between running jest vs. tsdx test... at least for my project, they are exactly the same. What needs to be upgraded?
3. It complicates tsdx for really no actual benefit today. If this is intended for upgrades, I'd consider this a premature optimization.

[agilgur5]

I think a TSDX Jest preset would be helpful (so would an ESLint one and a Babel one) as all these integrations then become one-liners. Something I previously mentioned in #389 (comment)

[kylemh]

@lookfirst it's not a premature operation, that's the sole existence of this platform... Remove configuration and allow for a simpler dependency upgrade strategy a lá create-react-app. It's mentioned in the first paragraph of the README. I'd say you have a valid reason for wanting an easier way to opt-out though.

I'm interested in that as well, but it's important to acknowledge were going against the grain of his goal. I think @agilgur5's idea for presets is stellar. Maintain what currently occurs, but maybe allow for a way to make the config files for each tool with the preset defined.

[lookfirst]

@kylemh I said optimization and so far, tsdx test has proven to complicate things and not remove any configuration whatsoever.

[kylemh]

It removes a large portion of what I would need to define in my Jest config

[lookfirst]

... and in my case the command does nothing productive, because I use an IDE that needs the file.

The whole point of this issue is to allow the file to be generated automatically. If the file is generated automatically, you don't need the command. 🥇

Large is relative... my file is just a few simple lines.

[kylemh]

If the file is generated automatically, there’s no way to support backwards compatibility for future changes to the Jest config from within TSDX.

Again, I’m not disagreeing saying we don’t need a way to help you out, but the solution you’re offering of just exporting the config file by default is a bad idea for most users who aren’t editing the config and don’t use a JetBrains editor, because it ruins the ability for the team to adjust the config and ship the update as a non-breaking change.

[lookfirst]

There is always a way, it is code, not rocket science. Updating the file is exporting it again and merging the diff. That is what revision control is for.

[agilgur5]

And the test experience is being improved by me and other contributors. The config is currently small, but issues like not using the same Babel config for tests (#383), monorepo support (#122 and some others), auto-mocking assets (#414), etc, etc, are certain to make it larger over time. And bugfixes in tsdx test or a preset means you don't have to patch every single jest.config.js you have.
I think we can agree that TSDX can make that simpler for you, and that's the goal. I also think most people don't like being overwhelmed in configuration, which is why CLI tools like TSDX, CRA, and many others exist and are very popular.

To get into some specifics:

Updating the file is exporting it again and merging the diff. That is what revision control is for.

Having to manually update is a poor experience. Especially when you use TSDX in multiple libraries, that gets frustrating fast. That's similar to a breaking change. TSDX users shouldn't have to do that.

If the file is generated automatically, there’s no way to support backwards compatibility for future changes to the Jest config from within TSDX.

I think if we use a preset or other method that allows you to do something like require('tsdx/dist/jestConfig'); then we'll be able to automatically roll-forward most people who needed to customize their config.
When it comes to breaking changes, I think I agree that the more that's handled inside TSDX, the better, as the surface area is smaller. Like I had to make some workarounds in #504 because we couldn't just roll-forward tsconfig.json settings. Maybe the default tsconfig.json should extend from tsdx/dist/tsconfig.json in a similar way to presets to reduce that surface area.

[jaredpalmer]

This is getting too heated folks.

[jaredpalmer]

• tsdx test will stay. Most users touch nothing when they use tsdx and we should keep it that way. This is the goal of the project.
• We should, however, make it more pleasant to use your own jest setup if you want to

[agilgur5]

Copying from something Jared said in #118 almost a year ago:

I think someone tried to solve this in #75, but this generated absolute paths to tsdx's jest plugins.

So some of the requirements are currently:

• Fixing any path issues. A preset might handle that without much fuss.
  • Create a preset
    • We'll need to migrate to a monorepo to set-up presets (and possibly handle some monorepo-related issues when doing so)
    • Ensure the preset merges your config correctly (it might break current tsdx test usage)
• Read .babelrc configs, c.f. tsdx test does not pull in options from .babelrc #583
• Use TSDX's built-in Babel plugin that's used for build, c.f. Jest does not work with macros -- build babel config is not used for test #383. The plugin is also intertwined with some runtime config so that one's a good bit of work and may not be fully possible.

Just listing all those so everyone knows the status; that's why there's a hold-up on this, sorry about that 😓

In the meantime, I did get tsdx test to integrate with VSCode's debugger with my config in #577 (comment) . Can use that as another workaround too.

[tiguchi]

I just figured out a workaround for IntelliJ IDEA that allows you to use tsdx test using a custom Jest run configuration. You can modify your project's Jest template directly, so those settings will be inherited by all new unit test runs.

The configuration needs to look like this:

• If you have a jest.config.js file with some custom overrides, specify that under "Configuration file"
• Select the node_modules/tsdx directory as "Jest package"
• Set your project's root directory as "Working directory"
• Add test to "Jest options"

With those settings it's possible to start tests from within the IDE.