[FR]: Recommended way to refer to a central jest.config.js

[lromor]

What is the current behavior?

Currently there's no way to refer to a jest configuration situated in parent packages. The current solution is to copy jest.config.js in each folder.

Describe the feature

Have an argument or a type to refer to the common jest.config.js. Something similar to ts_config? I suspect I could write a macro and perform a copy_to_bin, but I'm not sure if it's the right approach.

What do you think?

Fund our work

• [ ] Sponsor our open source work by donating a feature bounty

[lromor]

My current solution is to simply create a ts_project:

ts_project(
    name = "jestconfig",
    srcs = ["jest.config.ts"],
    tsconfig = {
        "allowJs": True,
    },
    allow_js = True,
    deps = [
        "//:node_modules/@types/node",
    ]
)

which can now be referenced as a config and is correctly resolved. Maybe I could wrap this into a macro and that should be it. Anyways, thank you aspect-build for making such a solid bazel framework for javascript and alike. Really beautiful work!

[Aghassi]

I was talking to @mattem about this and the pattern I'm considering doing to keep editor support is to just make a config that is exported as a first class NPM package and then referenced like one. This gives you two things:

1. IDE support and editor support (just use extends in the config and don't worry about the rest)
2. You get the config for free through the node_modules graph that rules_js provides

At least, that is what we are gonna try and pursue

[gregmagolan]

Is the problem you're hitting when your jest config is in a parent package that you need a copy_to_bin there so that you can pass it to the jest_test config attribute?

Using a ts_project to transpile your jest.config.ts to a jest.config.js is a fine way to go IMO. If your jest config is already a js file then you could alternately use a js_library instead of a copy_to_bin which is cleaner to read.

[Aghassi]

I'm chiming in here again because we are crossing this bridge. The solution/pattern I've always used is to make your central config an NPM package and then have other npm packages rely on it via workspace:*. Then those apps have jest.config.js which imports a config normally. Finally, you can have jest_test point the jest_config bit at the local file to the package. Does that make sense?