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

[lookfirst]

Oh hey, look at that... watch mode has been reverted.

Get rid of tsdx test and all this goes away.

#421

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

[lookfirst]

Wow, just going through recent commits, I noticed another bug related to jest... #499... this wouldn't exist if tsdx test didn't exist. I can fully understand the desire to make things 'simple', but so far, I think the complications outweigh the benefits. tsdx test-generate outputs jest.config.js and bam... tsdx steps out of the way. No more issues.