Allow to store wallaby config in subfolder and use relative paths in files and tests lists

[fvanwijk]

My config is in /tools/wallaby and my specs are in /test/specs. I cannot manage to let the message "No files with tests found, check your tests list patterns." disappear from the console. If I move the config file to the project root, everything works fine.

I tried to prepend "../../" to my (test)file patterns, without result. Prepending wallaby.localProjectDir + "/../../" doesn't work either. Is it possible have the wallaby config in a subdir? I prefer to have the option to set the localProjectDir manually instead of always having the localProjectDir relative to the config file.

Side note: the localProjectDir on the wallaby object does not end with a / so it is unsuitable to just prepend it to your file paths.

[ArtemGovorov]

At the moment wallaby config can only be placed in the root folder (equal or above tests and files). Thanks for the idea, changing project dir setting is a good option that we should support.

[ArtemGovorov]

And thanks for your note about localProjectDir ending, will fix it.

[ArtemGovorov]

localProjectDir ending is fixed

[vjpr]

+1 I too, would like to keep my config in a sub-directory.

[nevadascout]

+1

[mdoleh]

+1 I would especially like this if it worked with the path for the test runner as well.

[fvanwijk]

Any news on this? Additional to this issue I'd like to set a base path and be able to move the config file around.

[ArtemGovorov]

@fvanwijk No news yet, I'll post some updates here when there's some news.

[kimballjohnson]

one of the first things I ran into. please +1

[DinisCruz]

I really would like this since I really want to keep the files in specific folders

[rcazangi]

+1

[asnov]

I also put wallaby.js in the subfolder - just to make fast test some small small staff - don't want to change the main wallaby.js in the root. And got the next error: Runtime error: jasmine node module is not found or the version is not supported, missing npm install jasmine --save-dev? Cannot find module 'jasmine'

node_modules folder is one level up. jasmine installed. In the root project folder it works. Any advices?

Here is my config:
files: ['./**/*.ts', '!./**/*.spec.ts'], tests: ['./**/*.spec.ts'], env: { type: 'node'}, testFramework: 'jasmine', compilers: { '**/*.ts': wallaby.compilers.typeScript() }

[ArtemGovorov]

@asnov You can try and use this approach and add this to your wallaby config in the subfolder:

...
var path = require('path');
process.env.NODE_PATH = path.join(__dirname, '..', 'node_modules');
...

don't want to change the main wallaby.js in the root

If it's the only reason, then your other options is to just move your subfolder's wallaby config to the root by giving it a name different from your main wallaby config.

[jarekb84]

Another vote for this. As others have said, given the amount of config files for webpack, babel, karma, and variants thereof for different environments or testing approaches, it's beneficial to get them out of the root dir. Also, if my whole team isn't using wallaby, I don't want to have to distract them with a file most don't need.

[paibamboo]

+1

[epitaphmike]

+1

[boneskull]

I also have a use case where I want to provide a common config stored in a separate Node.js module.

I can't set NODE_PATH by walking up to the desired parent directory. The config would live in, say, my-project/node_modules/my-wallaby-config/wallaby.config.js. But my-wallaby-config is a symlink.

For now, the workaround is to symlink my-project/node_modules/my-wallaby-config/wallaby.config.js to my-project/wallaby.config.js.

[ArtemGovorov]

@boneskull In your case, wouldn't this work:

my-project/wallaby.config.js:

module.exports = require('my-wallaby-config/wallaby.config');

[boneskull]

yes, thanks--that's another workaround, and I've had to do similar things for other tools. I was hoping to eliminate the boilerplate altogether--though reducing it is better than nothing!

[kuechlerm]

Are there any updates on this issue? Thanks.

[ArtemGovorov]

@kuechlerm Not at the moment, but I'll post an update here when there's some.

[JimiC]

@ArtemGovorov 3 years later, maybe it's time to make this a priority.

[jmeischner]

+1

[jason-covington]

+1 Any updates on this?

[smcenlly]

We don't have any update on this issue to share. Having said that, we are embarking on some big architectural changes to Wallaby in 2024 that may see this change.

Our preferred approach (generally) is to try and automatically configure Wallaby for your project vs. requiring a configuration file, and so our efforts have been to push more in that direction. @jason-covington-auctane - I'm assuming Wallaby with automatic configuration does not work for your project?

[jason-covington]

Correct, we recently moved over to Vite and Vitest from Webpacker and Jest. if I add the wallaby.js it works fine.

module.exports = () => ({
  autoDetect: true,
  testFramework: {
    configFile: "./vite.config.ts"
  },
});

[smcenlly]

@jason-covington-auctane - you should be able to completely remove your Wallaby configuration file and start Wallaby using the automatic configuration feature.

[mikerouxfr]

I tried the following:

const path = require("path")

module.exports = wallaby => { return {
    localProjectDir: path.resolve(wallaby.localProjectDir, `..`),
    compilers: {
        "**/*.ts?(x)": wallaby.compilers.typeScript({ 
            module: `CommonJS`
        })
    },
}}

Sadly, from the dirty test of adding a console call as value, I think localProjectDir keeps its old value after the export.

const path = require("path")
module.exports = wallaby => { return {
    localProjectDir: console.debug(path.resolve(wallaby.localProjectDir, `..`)),
    // ...
}}

​[Info]​ C:\coding\wallabyNotInRoot
​[Info]​ Started Wallaby.js Core v1.0.1501
​​[Error] Looks like none of the paths specified in your files/tests list exist in C:\coding\wallabyNotInRoot\tools.​​
​[Info]​ Wallaby App (realtime reports) is available at: http://localhost:51245
​​[Error] No files with tests found, check your tests list patterns.​​
​[Info]​ Can't determine tests to run for the change, re-running all tests.
​[Info]​ To prevent the full test run when can not determine tests to run, use `runAllTestsWhenNoAffectedTests: false` configuration option.

[smcenlly]

@mikerouxfr - we're not entirely sure what you were attempting to configure, or whether it's something we currently support. The Wallaby configuration must be in your project root, and cannot reference files above your project root.

If you have a specific configuration question, we'd be happy to help. If so, would you mind creating a new issue?

[mikerouxfr]

I was trying to store Wallaby config in a subfolder and use relative paths in files and tests lists.

My post here was/is more to share about failed tentatives so other "googlers" can relate, or not spend time trying the same things, while adding more data/examples to this thread.

My Jest config is within the package.json.

Root folder

Initial configuration working properly.

Structure:

├── node_modules
├── sources
│   ├── utils
│   │   └── calc.ts
│   └── main.ts
├── tests
│   └── calc.test.ts
├── tools
│   ├── awesome-calc.code-workspace
│   └── tsconfig.ts
├── .gitignore
├── package.json
└── wallaby.js

wallaby.js content:

module.exports = wallaby => Object({
    autoDetect: [`jest`],
    compilers: {
        "**/*.ts?(x)": wallaby.compilers.typeScript({ 
            module: `CommonJS`
        })
    },
    files: [
        `./sources/**/*.ts`,
        `./sources/*.ts`,
    ],
    filesWithNoCoverageCalculated: [
        `./sources/**/index.ts`,
    ],
    name: `Awesome Calc`,
    tests: [
        `./tests/*.ts`,
    ],
})

Everything works as expected!

Move wallaby conf to a subfolder

Structure:

├── node_modules
├── sources
│   ├── utils
│   │   └── calc.ts
│   └── main.ts
├── tests
│   └── calc.test.ts
├── tools
│   ├── awesome-calc.code-workspace
│   ├── tsconfig.ts
│   └── wallaby.js
├── .gitignore
└── package.json

Updated wallaby.js content:

module.exports = wallaby => Object({
    autoDetect: [`jest`],
    compilers: {
        "**/*.ts?(x)": wallaby.compilers.typeScript({ 
            module: `CommonJS`
        })
    },
    files: [
        `../sources/**/*.ts`,
        `../sources/*.ts`,
    ],
    filesWithNoCoverageCalculated: [
        `../sources/**/index.ts`,
    ],
    name: `Awesome Calc`,
    tests: [
        `../tests/*.ts`,
    ],
})

Console output:

‍​[Info]​ Started Wallaby.js Core v1.0.1501
​[Info]​ Wallaby App (realtime reports) is available at: http://localhost:51245
​​[Error] No files with tests found, check your tests list patterns.​​
​[Info]​ Can't determine tests to run for the change.
​[Info]​ To run all tests when can not determine tests to run, use `runAllTestsWhenNoAffectedTests: true` configuration option.

Perhaps move the file without changing it

I thought: as I open my editor at the project root, maybe not target the parent dir but still the current dir. Without moving the file, reverting the ".." to ".", I get this feedback in the console:

‍​[Info]​ Started Wallaby.js Core v1.0.1501
​​[Error] Looks like none of the paths specified in your files/tests list exist in C:\coding\awesome_calc\tools.​​
​[Info]​ Wallaby App (realtime reports) is available at: http://localhost:51245
​​[Error] No files with tests found, check your tests list patterns.​​
​[Info]​ Can't determine tests to run for the change.
​[Info]​ To run all tests when can not determine tests to run, use `runAllTestsWhenNoAffectedTests: true` configuration option.

Add the runAllTests option

Adding the option mentioned in the last error message (runAllTestsWhenNoAffectedTests: true) yields:

‍​[Info]​ Started Wallaby.js Core v1.0.1501
​​[Error] Looks like none of the paths specified in your files/tests list exist in C:\coding\awesome_calc\tools.​​
​​[Error] No files with tests found, check your tests list patterns.​​
​[Info]​ Can't determine tests to run for the change.
​[Info]​ To run all tests when can not determine tests to run, use `runAllTestsWhenNoAffectedTests: true` configuration option.

Seems the only difference is that the local web app does not start in this case.

Tentative from my previous comment

Then, reading the doc at wallabyjs.com/docs/config/overview, I figured I could try to hack a little and just override the value of localProjectDir.

So I tried changing the value of localProjectDir and it does not solve the "issue".

Here is the content of the wallaby.js along with the console output.

const path = require(`path`)
module.exports = function(wallaby) {
    console.debug(`localPjtDir before =>`, wallaby.localProjectDir)
    wallaby.localProjectDir = path.resolve(wallaby.localProjectDir, `..`)
    console.debug(`localPjtDir after =>`, wallaby.localProjectDir)
    return {
        autoDetect: [`jest`],
        compilers: {
            "**/*.ts?(x)": wallaby.compilers.typeScript({ 
                module: `CommonJS`
            })
        },
        files: [
            `./sources/**/*.ts`,
            `./sources/*.ts`,
        ],
        localProjectDir: wallaby.localProjectDir,
        name: `Awesome Calc`,
        tests: [
            `./tests/*.ts`,
        ],
    }
}

​[Info]​ localPjtDir before => C:\coding\awesome_calc\tools\
​[Info]​ localPjtDir after => C:\coding\awesome_calc
​[Info]​ Started Wallaby.js Core v1.0.1501
​​[Error] Looks like none of the paths specified in your files/tests list exist in C:\coding\awesome_calc\tools.​​
​[Info]​ Wallaby App (realtime reports) is available at: http://localhost:51245
​​[Error] No files with tests found, check your tests list patterns.​​
​[Info]​ Can't determine tests to run for the change.
​[Info]​ To run all tests when can not determine tests to run, use `runAllTestsWhenNoAffectedTests: true` configuration option.

Closing word

If it is unrelated, sorry for posting here! It's the best thread I could find talking about "my issue". I can gladly open a new issue and attach a test project if needed. Let me know!

Adding a quick question by the way: In my research, I could not find a way to set the Wallaby config within the package.json with a TS project. This would be a viable solution to me. To confirm I did not miss something important, is it possible?

[smcenlly]

I was trying to store Wallaby config in a subfolder and use relative paths in files and tests lists.

My post here was/is more to share about failed tentatives so other "googlers" can relate, or not spend time trying the same things, while adding more data/examples to this thread.

Thanks - I can tell you that it definitely is not supported. There are a number of non-trivial/fundamental changes that we would need to make to Wallaby to support this.

Adding a quick question by the way: In my research, I could not find a way to set the Wallaby config within the package.json with a TS project. This would be a viable solution to me. To confirm I did not miss something important, is it possible?

Since you are using wallaby.compilers.typeScript, there is no way to add this to your package.json.

What version of jest are you using?

[mikerouxfr]

$ npm jest --version
8.13.2

Jest config from the package.json file:

    "jest": {
        "preset": "ts-jest",
        "moduleDirectories": [
            "<rootDir>/node_modules",
            "<rootDir>/sources"
        ],
        "verbose": false
    },

Makes me think I did not investigate Jest config much yet 🤔

[smcenlly]

npm jest --version is your npm version, not your jest version.

To determine your jest version, use npx jest --version.

[mikerouxfr]

My bad 😇

$ npx jest --version
29.7.0

[smcenlly]

With your Wallaby/Jest configuration, Wallaby will ignore the compilers section of your configuration as it's covered by jest's transforms (ts-jest).

I would think you can move all of your configuration to the package.json.

Having said that, if npx jest from your project root runs the tests that you want, you should be able to remove your Wallaby configuration entirely and use Wallaby's automatic configuration.

[mikerouxfr]

True, it works!

I haven't tried to delete it in some time. I started without a Wallaby file but end up creating one for some reason and never dared to remove it. So yes, for anyone who finds this post by searching, the solution suggested above is currently functioning!

Thanks for the support and for the tools!