npx tailwindcss .... --watch is locking my files

[Montago]

I've installed the latest version of Tailwind (December 2022) and am using this guide :
https://chrissainty.com/adding-tailwind-css-v3-to-a-blazor-app/

using this command:
npx tailwindcss -i ./app.css -o ./wwwroot/css/app.css --watch

While editing the Blazor files, the Powershell terminal compiles my CSS and is somewhat working fine.

However - at some point i can't save the Razor / CSHTML files in Visual Studio because the files are locked by NPX / Node
I then have to close Powershell / Tailwind builder to save my files.

Ultimately - i would much rather like to work with a pre-compiled subset version of Tailwind but have had a hard time finding the right way to select which features i want. That way i would have functioning Intellisense in Visual Studio.

[thecrypticace]

Hey! This is definitely weird. We open files temporarily to read them for changes but they should then be closed as soon as the read is done. Can you provide details on:

1. What version of Windows you're on
2. The storage your files are on (Hard Drive vs SSD)
3. What version of Visual Studio you are using?

Visual Studio especially has some super weird quirks that other editors don't exhibit so it's probably something specific to the way it works with files that is causing the problems there.

[Montago]

Hi, thanks for replying just after christmas :)

1. Windows 11, the newest public build
2. Its an M2 SATA SSD (Laptop)
3. Its Visual Studio 2022, version 17.4.3

I'm wondering if if the problem is because i'm running in debug mode on/off that Visual Studio somehow clashes with the NPX watch. The way i develop is that i'll startup the Blazor app and then edit the Razor / CSHTML files to style up the app.
Visual Studio build will sometimes complain that i've edited too much to live update so it needs to restart.

I guess i could try using the Dotnet run method in VSCode instead which seems to work better.

[thecrypticace]

Hey! Just getting back around to this (we were off for Christmas break). So a few things:

1. I'm not seeing file locking behavior. However, I don't use Visual Studio much. If you could provide a reproduction repository with instructions that would be useful.
2. Can you provide screenshots and/or video of the behavior you are seeing?
3. Regarding your "compiled subset" idea

You can use the "safelist" config option with regexes for this: https://tailwindcss.com/docs/content-configuration#safelisting-classes

It does have some caveats though, especially for things involving colors, you should be careful not to make your regex match too much because you'll end up with extremely large CSS files that 1) take a long time to build 2) the browser's can't even handle most of the time.

[Montago]

1. sample repro:
   BlazorApp1.zip

I'm running "npx tailwindcss -i ./base.css -o ./wwwroot/app.css --watch" in the root of the folder.

and then in order to run the app, you can run this command in Powershell: "dotnet run build"
and then open the webpage that it prints out in the terminal.
alternatively you can run the project in Visual Studio 2022 simply by running in debug mode.

While running the watch in npx - you edit the razor files (/Pages or /Shared) if you edit C# in those files they will force Visual Studio to rebuild or the dotnet runner to "crash" and you then need to restart it.

at some point you cant save the file in Visual Studio because it is locked by NPX

[Montago]

What the version are you using..

• Tailwind : The newest available
• VSCode : The newest available
• Visual Studio 2022 Professional : The newest available : 17.4.3
• Windows 11 : The latest public build 22H2 (22621.963)

[thecrypticace]

I've been spending quite a bit of time trying to get that repo to work however:

1. The Tailwind Config is not correct to cover any of the source files. I fixed this durning my testing.
2. No changes to C# source code seem to result in rebuilds or crashes of the runner. In fact, it's not reacting to changes at all until I stop and restart the build process.
3. You didn't provide what you are seeing so I'm not 100% sure what errors you are getting where. For example, you say that node has locked the file and Visual Studio can't save it. What does the error in this situation look like? Do other editors exhibit the same behavior?

Figuring this one out might well require someone with more knowledge of windows and visual studio and how it works. I'd love to help track this one down but the CLI doesn't lock files when watching / reading so all of this is rather confusing.

I've moved this to a discussion so if anyone else happens to see this and can provide some insight that would be super helpful.

[thecrypticace]

Something that could also be a possibility: Security software on your device could be temporarily locking files on read on behalf of the system. That would be entirely outside our ability to control though.

[MatthewKing]

For what it's worth, I'm experiencing this same issue using Tailwind 3.2.4 and Visual Studio 17.4.4 when developing a Blazor application.

What seems to happen to me is as follows: When I save a file within Visual Studio, there is a delay between saving the file and the Tailwind CLI printing "Rebuilding..." followed by "Done in XXXms". If I attempt to save the file again during that delay, I will get a "Save File As" pop-up in VS, indicating that the file is locked. Once the Tailwind CLI has finished what it was doing and has printed "Rebuilding... / Done in XXXms" then I can save the file again safely. So the issue only occurs when hitting save twice in relatively quick succession.

Hope this helps.

[Montago]

@MatthewKing the thing is, at least in my experience, visual studio will continue not being able to save the file because its locked by the npm watcher.

I need to close the watcher in order to save the file.

[MatthewKing]

Looking at this further, I reckon this has something to do with how the Tailwind CLI is watching the file system in conjunction with how Visual Studio writes files. I noticed something that looks like it might be backoff or debouncing from the Tailwind CLI - the time it takes to rebuild was not linear with the number of times I write to the file in quick succession. With this in mind, I tried adding the --poll flag to the CLI, so that it uses polling instead of a filesystem watcher. This resolved the issue I was seeing with Visual Studio, so could be a good workaround for @Montago to try, and perhaps a clue for @thecrypticace or other maintainers to investigate. Cheers!