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

https://github.com/jaredpalmer/tsdx/pull/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 https://github.com/jaredpalmer/tsdx/issues/389#issuecomment-568866380

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

[agilgur5]

@lookfirst TSDX is far from the first "zero-config" CLI in existence, others have test capabilities too. You could make the same argument for every other CLI if you wanted to. Same can be said for pointing out bugs in software -- all software has bugs. I have contributed fixes to literally every part of TSDX (39 PRs and counting), most of which fall into tsdx build, which it sounds like you're still using despite all the bugs.

You are free to suggest changes, point out bugs, be critical of a feature, etc but some of your comments go further than that and can be overbearing -- I don't believe that's warranted or productive.

Fact of the matter is that people clearly use this feature. Including multiple people in this thread and including me. In some of my libraries, I have 0 test config what-so-ever and just use tsdx test out-of-the-box. Your use case is just that -- a use case. Others use it differently and as such haven't run into this. The decision to remove a feature should certainly not be based on a single use case. Especially not one which can still be optimized with a preset or something like it.

The original premise remains to generate a file and yes, we should do that to let you simplify any custom config and make for easier integrations. No one is disagreeing with that.

[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 (https://github.com/jaredpalmer/tsdx/issues/383), monorepo support (https://github.com/jaredpalmer/tsdx/issues/122 and some others), auto-mocking assets (https://github.com/jaredpalmer/tsdx/issues/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.

[lookfirst]

(39 PRs and counting)

Co-founded Apache Jakarta. One of the first Apache Members. Been contributing to hundreds of open source projects across multiple groups and languages for 25+ years now. And, who cares?

You are free to suggest changes, point out bugs, be critical of a feature, etc but some of your comments go further than that and can be overbearing -- I don't believe that's warranted or productive.

Oh come on, no I am not. Just because you don't agree with the direction or suggestion to really simplify things, doesn't mean it is overbearing.

Having to manually update is a poor experience.

Agreed. Automate it. I gave that as an example to move the discussion forward, not as an actual solution, which should definitely be automated.

That's similar to a breaking change. TSDX users shouldn't have to do that.

Agreed. tsdx test has already given us one breaking change. Along with several issues of confusing behavior. How much more do you need?

[lookfirst]

https://github.com/jaredpalmer/tsdx#npm-test-or-yarn-test

"Runs the test watcher (Jest) in an interactive mode."

Runs in interactive mode?

[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. #583
• Use TSDX's built-in Babel plugin that's used for build, c.f. #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 https://github.com/jaredpalmer/tsdx/issues/577#issuecomment-600866819 . Can use that as another workaround too.

[jaredpalmer]

@agilgur5 gave u publish rights. Go ahead a cut a release

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