Resolve new configs in shallow-cloned monorepo on CI

[hasparus]

Pull Request Name

Resolve new configs in shallow-cloned monorepo on CI

Description

If the config path changed, we now resolve even if the new and old configs were modified at the same time. This helps with monorepos in shallow clones on Continuous Integration environments.

I plumbed the newConfig flag down to loadConfig function, as we've already modified the previous path.

Type of change

• Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested?

I lazily ran this on CI in a PR I'm working on: graphql-hive/console#5466

Would probably need a proper e2e/integration test.

Test Configuration:

• OS + version: macOS Sonoma 14.6.1
• NPM version: 10.8.2
• Node version: 22.5.1

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• Any dependent changes have been merged and published in downstream modules
• I have checked my code and corrected any misspellings

[devalberg]

This seems to also be fixing an issue I'm having with VSCode's ESLint extension in my monorepo.

Which is: whenever I open a file from a lib/app that doesn't have an eslint config (like suggested here, the plugin's linting will fail and won't update until I restart the ESLint server (VSCode's extension). But then if I open the file again it's back to the broken state.

I'm quite certain the config is setup correctly as running lint through CLI reports everything as expected, no matter if running from monorepo root or from the library's root. It's only the VSCode ESLint extension.

After everything I've tried (also setting eslint.workingDirectories like in the linked issue). Nothing seems to do it until I tried applying this patch.

It is quite frustrating to say the least 😔

Here's a video demonstration:

Screen.Recording.3.mov

---

Setup is pretty simple:

.eslintrc.json in monorepo root:

{
  root: true,
  extends : [
    // ...
    "plugin:tailwindcss/recommended"
  ]
  // Nothing else specifcally setup for eslint-plugin-tailwindcss
}

eslintrc.json In apps/libraries with tailwind config:

module.exports = {
  extends: ["../../.eslintrc.json"],
  settings: {
    tailwindcss: {
      config: require.resolve("./tailwind.config.js"),
    },
  },
};

The tailwind.config.js are also pretty straight forward:

const { createGlobPatternsForDependencies } = require("@nx/react/tailwind");
const { join } = require("path");
const baseConfig = require("../../libs/styles/tailwind.preset");

/** @type {import('tailwindcss').Config} */
module.exports = {
  presets: [baseConfig],
  content: [
    join(__dirname, "{src,pages,components,app}/**/*!(*.stories|*.spec).{ts,tsx,html}"),
    ...createGlobPatternsForDependencies(__dirname),
  ],
};

Is this also an issue others are facing? Or am I missing something completely?

[hasparus]

@devalberg I'll try to keep my fork up to date until @francoismassart has time to look into this.

https://github.com/hasparus/eslint-plugin-tailwindcss

[CosAnca]

@devalberg I'm also facing this issue in VS Code in a similar monorepo configuration and as you said the only solution is to restart the ESLint server. I hope this PR will be merged in soon.

[hasparus]

@francoismassart should I add end-to-end tests for this?