Open tommytayman opened 10 months ago
We have the same exact issue! Were you able to find a more permanent solution?
@eademi - Sorry, no. We're not using .scss
quite yes but have plans to in the near future. Knowing that we would be doing some .scss
work is what initially prompted me to update our bundling solution. The only way that I have found is just to leave EnableTagHelperBundling
to true in local development which makes tracking down JS errors a bit more problematic.
I'm hoping the library authors will be able to patch this up prior to us getting to .scss
processing. I would submit a PR with my proposed fix, but not sure if there are other implications of removing that line.
@tommytayman We ended up using another package (AspNetCore.SassCompiler) for compiling .scss into .css and we only use WebOptimizer.Core for bundling and minifying. Thanks again!
@eademi - Nice! May look into this as well
@eademi @tommytayman what is the issue with EnableTagHelperBundling =true, what problems we have in JS debugging, I am intending to use this extension, are there any problems to use in prod, and what advantages does AspNetCore.SassCompiler have over weboptimizer.saas, i find weboptimizer.saas easier to use
@AJKKarthik024
what is the issue with EnableTagHelperBundling =true, what problems we have in JS debugging
this does not impact anything JS related nor EnableTagHelperBundling=true
. The issue is around .scss files and when 'EnableTagHelperBundling=false'. When you have this set to false, each styling file is listed individually but WebOptimizer
is changing the .scss
extension to .css
which causes a 404 error. If the extension was not changed, then .scss
files would render correctly both when bundling and when not bundling.
are there any problems to use in prod,
None that I've seen. We've been using this for a month or so now with no issues.
and what advantages does AspNetCore.SassCompiler have over weboptimizer.saas,
I can't speak to this as I have no experience with the other compiler.
@tommytayman ,i have one question, is there any way that when i place multiple scss files in layout like below
in multiple partial views those gets bundled dynamically based on all the sass files into single css and return to browser, instead of multiple network calls
I am facing this issue today as well and noticed the line of code you highlighted. My use-case is exactly the same as yours. In development I want each scss file listed out from the taghelper but the file extension gets changed. I have tried playing with a custom IFileProvider but can't seem to get anything to work.
I ended up in implementing an extension method that registers the missing routes by taking each source file and replace the extension .scss
with .css
internal static class WebOptimizerExtender
{
internal static void AddCustomScssBundle(this WebOptimizer.IAssetPipeline pipeline, string route, params string[] sourceFiles)
{
foreach (string sourceFile in sourceFiles)
{
// add single source file as "bundle"
string cssRoute = sourceFile.Replace(".scss", ".css", StringComparison.OrdinalIgnoreCase);
pipeline.AddScssBundle(cssRoute, sourceFile);
}
// add the original (complete) bundle
pipeline.AddScssBundle(route, sourceFiles);
}
}
This could be combined with passing IWebHostEnvironment
to add the "single bundles" only in Development
environment for example
Background
We're in the process of replacing the Bundle & Minify plug-in with this library since it gives us better bundle flexibility in addition to compiling .sass files. During local development, we want to disable the EnableTagHelperBundling so we can get each file output for debugging specifically for our .js bundles.
Setup
Test Setup
to this
Expected Results
Since we want each file to render instead of the single bundle, we should expect to see
This works due to the request to simply render the individual files that make up this bundle and because this library will render a SCSS file as a minified CSS file upon request.
Actual Results
We can see that the extension has been changed from the link tag helper from
.scss
to.css
resulting in a 404 error on the server and no styles being rendered. Also note the lack of the ?v=Hash on these elements. The same issue affects the index page which directly references the/scss/a.scss
file here when theEnableTagHelperBundling=false
is set.Potential Solution
I cloned this repository as well as the
WebOptimizer.Core
repository. Next, I removed the NuGet reference from this project and referenced the local copy of the Core project directly. When I comment out this line of code the project returns the expected values in both the "un-budling" (render each file individually from a bundle reference) scenario on the Bundle.cshtml page and the direct reference on the Index.cshtml page.I am not familiar enough with this project to know what potential impacts removing that line of code would have, but it does seem to conflict with this library and un-bundling .scss files