Create a multi-config cli runner #2970
Comments
|
Another alternative could be moving config out of package.json into a |
|
That will not work for Facebook. The configurations are very different, even in the same codebase :( |
|
I'm not sure why that wouldn't work - in any folder where you currently have a package.json config, you could also have a |
|
We don't have package.json files for our monorepo and some projects are a subset of others. I believe what you are proposing is orthogonal to what we are trying to accomplish here. |
|
Wouldn't nested rc files, just like eslint, solve that? Each directory would define its own config, which would inherit from parent dirs but could override them. |
|
Typescript handles this pretty well with tsconfig.json in a sub-directory overriding the parent config. It's also relatively easy to implement, just keep searching parent paths till you find a config file. I'd be happy to take a stab at implementing if that solution would work. |
|
@japhar81 that won't work for us because we have setups where projects are actually nested with different includes/excludes patterns. It's a bit complicated :( |
|
@cpojer do you happen to have an example you can point me at? I'm having a hard time visualizing what you mean |
|
@cpojer even with |
|
As discussed yesterday at our team sync, the first step to this may be how we can separate our config system from global into local configs. There are a number of global settings, like whether to collect coverage, verbose printing, number of workers etc. as well as a ton of local configs, like the roots, all haste map and ignore patterns and which transform to apply. We probably need an RFC for that first before we continue with further decisions. |
|
I think it would be great if you could show us some real examples of systems which have mentioned complications. Currently they sounds too abstract, and to be honest, even unreasonable. Some my thoughts:
|
|
No offense but this looks like another NIH case combined with legacy cancer metastasizing in open source community. |
|
I apologize for not explaining myself better earlier and not sharing enough about this exploration. There is no legacy component that motivates solving this problem besides our internal Jest CLI which is a piece of legacy code that is hard to maintain. This issue is about offering a path forward for our internal infrastructure which isn't scaling as well and falling behind the open source version of Jest as well as open sourcing it because it may be of use to others. I'm trying to source ideas and write up what that multi-runner in open source may look like which may live inside of To provide a more concrete use case: assume Jest's |
|
I love this idea. Right now I'm using a few jestrc files, npm scripts, and the jest config option. But if there was a better way to organize this and have nested configs that would be pretty fantastic. |
|
@cpojer Thanks for reply!
Ah, finally I can clearly understand what you're trying to achieve. #2445 doesn't interfere with this issue, since it is about discovering top level config,. Particularly for this issue, most likely that you will need discovery features of #2445 anyway to locate top-level config (if such exists), which will tell Jest where to find all other tests and how to aggregate them. However, my reply here #2970 (comment) (except part 1, it is obviously no longer valid) still stands. It describes established community practice about how exactly what you're describing should be done in regards of located in subdirectory I don't see how it is orthogonal to what you're describing, or your descriptions again misses some important details. |
|
As a side note, while @mrhyde reply was quite harsh, I think it was justified, because your previous replies made strong impression that you were trying not to solve issue, but patch it by building whole new feature around system (Facebook's codebase) which were flawed in its core and deny all other existing solutions just because it doesn't work for Facebook codebase. I think we all understand that compromises should be taken here, but they shouldn't serve as a basement for building new features, because this is obviously bad even for Facebook — it will just spread bad practice further instead of providing good reason to fix it. Well, I hope that's clear my and @mrhyde replies and that it's just a result of misunderstanding. |
Configjest-config/index.js const cosmiconfig = require('cosmiconfig');
const jestrc = cosmiconfig('jest', [options]);
module.exports = function (test) {
jestrc.load(path.dirname(test))
.then((result) => {
// result.config is the parsed configuration object
// result.filepath is the path to the config file that was found
})
.catch((err) => {
// do something constructive
});
};Pseudoconst config = require('jest-config');
const tests = [....tests]; // test === 'path/to/file.test.js'
tests.forEach((test) => run(test, config(test)));Usage$ jest # :) |
|
Config lookup after gathering all |
|
This is happening in the next version of Jest. We discussed a bunch more stuff in the team meetings and we are currently cleaning up things. |
|
@cpojer Did this actually happen? This topic is what shows up when you google the issue, it would be great to have this conversation end with a link to an example/documentation or update on the implementation. I'm looking around but I see a lot of discussions.. like this one: but it also ends with saying that it will happen... basically, Is this possible? With .jest.rc or somehow specyfing the paths that a given context should apply to? The moment I posted this comment, I found this: http://facebook.github.io/jest/docs/en/configuration.html#projects-array-string-projectconfig let's see.. |
|
The link to the docs you provide is correct |
|
Quick follow up on @lgandecki's comment. I have a very similar structure in my project (with a root Unfortunately it looks like sometimes jest wants to run tests using the nested config and sometimes without it. e.g. in packages/component-library running jest outputAs you can see, the same tests are being run twice. In the case of the On the other hand, jest --listTests outputMy `jest --showConfig`.Additional things to note:
|
|
Separate issue, please 🙂 |
|
@dan-kez did you fix your issue? do you have a repro? |
|
@sibelius I was able to resolve it by deleting the repo locally and re cloning it. I haven't had the issue again so I imagine it may be due to something weird in the cache. If you're having this issue I recommend giving that a try. |
|
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Right now,
jest-cliis great at watching and running a single config for a single project. However, at Facebook we have many projects within one repo and we have a (bad!) internal runner that can merge configs and run them all within one run. It also doesn't support the watch mode.We spent the past year separating modules for Jest, open sourcing more parts of our internal infra as well as rewriting Jest to support this use case in open source and bring it back in. This issue is to start the discussion as to what this may look like and how we could implement it. I can see this be implemented in two ways:
jest-alla package to run multiple configs within one run.jest-clito accept multiple configs.On first glance, the former seems easier than the latter. We could pull out the remaining pieces from jest-cli to make it really lightweight, separate the watch mode into a separate re-usable package and built a second test runner for the Jest testing platform. Most people will keep using
jest-clibut for large companies,jest-allwould become the default.The second solution is also exciting, however. The technical challenge here is, and this was set up deliberately to execute on this specific issue, how to go from one SearchSource, TestRunner and watch mode to many SearchSources that can pass tests to one TestRunner instances and the watch mode. Basically I can see an implementation of this work that changes the architecture like this:
{config, path}pair and runs those tests. The refactor is much harder than adding the ability to schedule tests with different configs within one TestRunner instance.HasteMapInstancewe'd operate on aSet {HasteMap1, HasteMap2, …}.I'm curious to hear other people's opinions on what they think is the best way forward to make this happen. The end goal will be to remove our legacy internal runner and replace it with this open source piece that we are building here.
The text was updated successfully, but these errors were encountered: