Feature request: wildcard support

[stefanloerwald]

Hi,

my underlying goal is to minimize the download of required css to just what is used on the displayed page, rather than downloading one big chunk of css (e.g. entire bootstrap, etc.) where 99% of css remains unused. So what I'm doing in my (blazor) application is to create component-specific style sheets. Of course those individual style sheets need to be compiled and minified as well, but it doesn't scale to configure that for each individual file.

What I would love is a regex-style input in the compilerconfig.json, e.g.

{
  "inputFile": "wwwroot/css/(.*).scss",
  "outputFile": "wwwroot/css/\1.css"
}

Is that something that could be considered for WebCompiler (and/or BundlerMinifier (of course more the minifier part than the bundler for obvious reasons))?

BR Stefan

[kelps]

I was wondering the same thing over the weekend (had a similar problem, but with Less instead of Sass). Since there isn't a better way to do this using the Nuget package (necessary for CI builds instead of using VS Extensions) I managed to create a workaround that solved my problem for now. In my case I created a Directory.Build.targets file (attached here) and added it to my project folder. After that I just added the following to my .csproj file, pointing to the .less files I wanted compiled. Since you're using Sass, just change the file extensions here and inside the .targets file and it should work.

<ItemGroup>
    <DynamicWebCompilerConfig Include="wwwroot/css/components/**/*.less" />
    <DynamicWebCompilerConfig Include="wwwroot/css/pages/**/*.less" />
</ItemGroup>

Directory.Build.targets.txt

Not the best naming conventions in this code and the code itself isn't very robust, but worked well here. I hope it works for you too until WebCompiler supports this, if it makes sense.

PS.: I had to rename the .target files to .txt in order to upload it here.

FYI: I just found out this does not work if you build using dotnet build or dotnet publish, because of the way I did. Only works in Visual Studio for now. I'll need to turn this into a proper Nuget package now.... Sorry for jumping the gun, but at least it points to a possible solution....

[kelps]

Update: After a little more digging, I found out that there is a alternative to the CodeTaskFactory that works cross platforms and with the "dotnet" commands. The alternative is RoslynCodeTaskFactory and it works the same way. So I updated my .targets file to use it and I am attaching the updated version here as well. The same code as before, only using a different kind of msbuild Task for the custom code.

Given that it was this "easy" to create the workaround, maybe a solution that works this way could be easily achieved in the current Nuget package, just by including new variables and a mechanism to generate the dynamic .json configuration in a similar way to what I did (but more robust, of course). My solution only cares about simple compilation of .less files, but it wouldn't be that hard to change it to to work with the other compilations supported by WebCompiler. I am kind of swamped at the moment (for the next 6 weeks at least), but I may take a crack and creating a pull request, if that "feature" is something @madskristensen would be ok with. I am also open for any suggestions to improve this workaround.

@stefanloerwald, I hope this helps. Feel free to ping me if you try this and have any problems.

Directory.Build.targets

[kelps]

Another Update: Ok, I hope this is the last "fix" to my workaround. After using the previous fix for another day, our team concluded it was causing some random/intermittent errors while building. I don't know the exact cause, but I suspect WebCompiler doesn't like running from 2 different .json configurations or it is missing the .json.defaults file in the secondary configuration. Anyway, the new solution I came up with was to change my workaround in 2 ways:

• It now dynamically generates the original complilerconfig.json. To avoid problems with merge conflicts, I removed that file from source control and added it to .gitignore. In our project, compilerconfig.json turned into a local only file, generated during the build process.
• I improved the code a little to only change the file when necessary. Since Visual Studio keeps building in background (for code completion), my code changing that file all the time causes WebCompiler to run a lot more than it was needed.

Looks like those 2 simple changes fixed all my issues. Every single build we ran after that worked without problem. Bellow is the new .targets file.

Directory.Build.targets

[stefanloerwald]

@kelps Wildcard support is now available in my dotnet core global tool version of this utility. It works with sass for now, so might not cover your use case yet. See https://github.com/excubo-ag/WebCompiler