MSBuild Target

[RichiCoder1]

Random idea, but would it be possible to create an MSBuild target to allow compiling the Sass before hand? I've put something like this together for my work when using Less. Reduces the startup hit for websites, and allows build time verification of Sass.

[aviatrix]

It's not impossible, but you will either need 1 central scss file that combines all scss files or an xml defining which goes where, having that would defeat the purpose of having bundling and minification package of MVC ( i'm guessing you are using that ) where you specify what goes where.

Also, the startup cost is mainly during development [1] and having to rebuild the whole project each time after scss change is made is a chore (at least for me) and i prefer it run time.

[1] if you are in Release mode bundling & minification builds the bundle only once on app start

[RichiCoder1]

Also, the startup cost is mainly during development [1] and having to rebuild the whole project each time after scss change is made is a chore (at least for me) and i prefer it run time.

[1] if you are in Release mode bundling & minification builds the bundle only once on app start

With MSBuild, you can take advantage of MSBuild inputs and outputs and only recompile when something has actually changed and only recompile that which has changed. Sass imports might throw a wrench in that, but that could be worked around. If some how enabled a "Compile On Save", that might also work to allow easy updating while developing in a TypeScript-esque way.

It's not impossible, but you will either need 1 central scss file that combines all scss files or an xml defining which goes where, having that would defeat the purpose of having bundling and minification package of MVC ( i'm guessing you are using that ) where you specify what goes where.

With the precompilation step, you still could do bundling and minification, you'd just be doing it against CSS rather then less. And the css results would just be dropped next to their sass counterparts. You could also add a project property where you can tell the MSBuild task to compile them all into a single file, or a file property that says that a file should be part of a set and get compiled into a certain file. You could also abuse @import, assuming I'm understanding it correctly, and just say only compile these files, and then those files would @import everything you want to group.

I agree, however that this would not be the most simple task. Would require just below TypeScript levels of integration.

[am11]

This is a pretty awesome idea. I think we can certainly provide couple of extension packages on top of LibSass.NET, such as:

1. LibSass.NET.Extensions.MSBuildTask (works with project events and let user specify the options in MSBuild file)
2. LibSass.NET.Extensions.TagHelpers (for ASP.NET Core apps; provides options to configure the output behavior: inline CSS with[out] embedded source-maps or save to file with regular/embedded source-maps)
3. LibSass.NET.Extensions.OwinMiddleware (takes the input from stream, implement custom importers, send the results as response)
4. LibSass.NET.Extensions.Commons (for custom importers/headers to download imports from URLs, FTP, git etc., most commonly used custom functions like image-url() and then extension methods Compile(bool writeToOutput), Compile(PostCompilationDelegate))

To keep things simple, bundling is a separate project. Consumer of Sass can always create a glue.scss or main.scss which includes everything to compose the project (e.g. bootstrap.scss from Bootstrap framework).

Importers: new feature called Custom Importers can full-fil the requirements in this area.

Minification: we now have working SassStyle.Compressed option provided by native LibSass. If consumer wants, they can further post-process the output with any kind of minifier (written in C#, node.js etc.), but again, out of scope of this project.