Going from 4.1.14 -> 4.3.3 obliterated the performance and DEBUG=* killed IDE (reason known)

[akomm]

Context: vite/vite-plugin.

Why would you tell, that .gitignore is supported, yet its not really supported as certain notations, like white-listing and wildecard-blacklisting are not understood.

I assume the issue actually silently started with oxide v4, but for some time, it appears, node_modules were generally ignored by default. With some of the updates between 4.1.14 and 4.3.3 this last guard has been removed, blowing up the performance - hmr times of 5-10 seconds, vs. previously ~100ms.

What is funny, trying to debug the issue with DEBUG=* foot-guned the dev server in an infinite loop, as the logs created by tailwind were not excluded (git-ignored though) and it lead to an infinite write-log-reload-write-load cycle that quickly created hundreds of megabytes logs within seconds, clicking which accidentally also crashed vscode.

I guess I will fall back to using @source, but I really struggle to understand why using a format you don't correctly support. Many people probably unnecessary believe everything is fine, but endure worse performance than needed, but not terrible enough like in my case, to realize that it could be much better.

[RobinMalfait]

Hey! Can you share a reproduction repo so we can take a look?

We use the Rust ignore crate that is used by many tools for .gitignore support (https://github.com/BurntSushi/ripgrep/tree/master/crates/ignore).

node_modules should still be ignored by default, unless you use @source to point to files/folders in the node_modules folder. The idea overal idea is that we only scan non-ignored text based files and files you explicitly reference via @source. If that's not the case in your project, then that's probably a bug (assuming @source isn't pointing to files in node_modules).

You should be able to use DEBUG=* with a single build command instead if the dev server is causing some issues.

The .log files should be skipped by default when scanning as well.

Can you share a reproduction repo, or as a minimum share one of those log files with your .css file setup?

[akomm]

Up to this moment and update I didn't use @source or source(...).

Reproduction right now can be difficult right now from my spot, also because the repo in which I did the upgrade has it fixed, committed and I'd need to strip a lot, before I can publish. But maybe I can do it later, its some work but not as big as some other projects, its a template for new projects we have, which I keep up to date. Hit the issue updating.

What I can do at least right now quickly, some details.
vite: 8.2.0
tailwindcss: 4.3.3
@tailwindcss/vite: 4.3.3
react-router: 7.18.2
@react-router/dev: 7.18.2 (<-- using vite plugin)

./app/root.css
Opting out of discovery and setting source was the only change needed between bad performance and good performance:

Note 1: is it possible that the new version's @import "tailwindcss/theme.css" layer(theme) triggered node_module scan, which earlier versions didn't?
Note 2: layers and imports more explicit in order to integrate it with the @mui modularCssLayers:

.gitignore being that (project top/root-level white-list /*):

logs look all the same, going through everything, including .git/*

import {reactRouter} from "@react-router/dev/vite"
import tailwindcss from "@tailwindcss/vite"
import {defineConfig, type Plugin} from "vite"
import {parseEnv} from "./app/.server/env.parse.ts"

export default defineConfig({
  plugins: [tailwindcss(), reactRouter(), checkEnv()],
  resolve: {tsconfigPaths: true},
  environments: {
    ssr: {build: {rollupOptions: {input: "./app.server/main.ts"}}},
  },
  optimizeDeps: {
    include: [
      "@mui/material",
      "@mui/material/styles",
      "@mui/icons-material",
      "@mui/x-date-pickers",
      "@mui/x-date-pickers/AdapterDayjs",
      "dayjs",
      "dayjs/plugin/customParseFormat",
      "dayjs/plugin/relativeTime",
      "dayjs/plugin/timezone",
      "dayjs/plugin/utc",
      "arangojs",
      "arangojs/aql",
      "zod",
      "nanoid",
      "clsx",
      "tailwind-merge",
      "class-variance-authority",
      "react-draggable",
      "jszip",
    ],
  },
})

function checkEnv(): Plugin {
  return {
    name: "check-env",
    buildStart() {
      parseEnv()
    },
  }
}

env.parse.ts is terminated in a way, that it doesn't go through the entire APP from withing the build.
Just blocks prod/dev build, when environment settings has some issues.

[akomm]

Aside: the explicit setting is a boon for me in any way, because now it doesn't scan build, .react-router, etc, which does improve the good performance prior to update even further. I was just surprised about this behavior after update and to me it looks like the white-list is not understood by the tooling. I should add: I actually did swap it for a black-list yesterday, before changing my root.css and it did also fix the issue. So it must be that.

[akomm]

On the above matter, independent of the main issue, a guess on the log-loop:

I did not check this, but I think it was loop was created by combo HMR+TW, because HMR triggered TW, which wrote logs, which triggered HMR, which triggered TW, [...].

Probably good idea to make logs a dot-file or place it in a dot-folder. They are more likely to be ignored by systems.