Css preprocessor?

[nojaf]

Consider adding a css preprocessor option like Sass or Less.
Because who writes plain old css these days?

[laskoviymishka]

This is easily handle by adding Sass or Less loader in webpack.config. Or you propose to made it in yo-templates? This possibly should be an option of generator.

[nojaf]

Yes indeed an extra option in the yeoman thing

[SteveSandersonMS]

Thanks for the suggestion. I'm not sure whether we'll handle it by adding further options to the generator, or by adding docs describing how to do it.

But it should be really straightforwards - just amend your webpack.config.js to specify a loader for your SASS/LESS/etc files. In that sense it's more of a webpack question than anything about this project, but I appreciate we should make that obvious in docs so people know there's no other hidden steps they need to follow :)

[RobCannon]

I highly recommend that you make it an option in the generator, otherwise you will get a lot of issues for people trying to set it up themselves.

[colltoaction]

I'm actually having trouble with getting sass to work with prerendering. Does anyone have a working webpack.config.js for sass?

EDIT:

I'm no webpack expert, but I made it work. I don't really understand the implications of the following settings, maybe someone can shed some light. Based on webpack-contrib/css-loader#59

            {
                test: /\.scss$/,
                include: /ClientApp/,
                loaders: [
                    'css-loader/locals?module&localIdentName=[name]__[local]___[hash:base64:5]',
                    'sass-loader'
                ]
            }

[shobman]

An option in the generator would go awesome. I'm having trouble getting it to work for less.

I added the loader to the webpack.config.js file directly after the existing .css line:
{ test: /\.less/, loader: extractCSS.extract('css!less') }

It works when i run 'webpack' directly at the CLI, but when I run 'dotnet run' there's an exception in the middleware when I make the first page request.

Exception:
Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware[0]
      An unhandled exception has occurred: Call to Node module failed with error: Error: Webpack compilation reported errors. Compiler output follows: Hash: 42861fb47b6854d4d6b6
      Version: webpack 1.13.1
      Time: 2609ms
                  Asset     Size  Chunks             Chunk Names
      webpack-output.js  19.6 kB       0  [emitted]  main

      ERROR in ./ClientApp/components/Counter.less
      Module build failed: Error: Cannot find module './../../node_modules/css-loader/lib/css-base.js'
          at Function.Module._resolveFilename (module.js:438:15)
          at Function.Module._load (module.js:386:25)
          at Module.require (module.js:466:17)
          at require (internal/module.js:20:19)
          at Object.<anonymous> (/Users/simon/code/Zenith.Core/src/Zenith.Core.Erp.Yo/node_modules/css-loader/index.js!/Users/simon/code/Zenith.Core/src/Zenith.Core.Erp.Yo/node_modules/less-loader/index.js!/Users/simon/code/Zenith.Core/src/Zenith.Core.Erp.Yo/ClientApp/components/Counter.less:62:19)

Has anyone got this working?

[colltoaction]

@shobman did you check my last comment? I couldn't make it work with extracttext, but it does without it.

[colltoaction]

I'm sorry, I was terribly wrong. The issue here is that we need different webpack bundles for both configurations (we need different module loaders for sass browser vs sass server as the webpack maintainers show here), but this is not supported by aspnet-webpack.

See how the configuration is tweaked to work in the backend here: https://github.com/aspnet/JavaScriptServices/blob/master/src/Microsoft.AspNetCore.SpaServices/npm/aspnet-webpack/src/LoadViaWebpack.ts#L37. And if you try to use an array as configuration (allowed by webpack as seen here) you get this exception https://github.com/webpack/webpack/blob/8ff6cb5fedfc487665bb5dd8ecedf5d4ea306b51/lib/MultiCompiler.js#L39.

This is effectively breaking one of webpacks features, and it makes me wonder if this is the correct approach. Maybe instead of overriding the configuration we could define two configurations, and let aspnet-webpack search for the one it needs.

I'm close to making this work by manually tweaking LoadViaWebpack.ts, I'll share when it does work.

[colltoaction]

Well, I made it work, but not 100% with angular2. Either you:

1. use extractCSS but lose style encapsulation
2. don't use extractCSS at all, at the cost of not having styles in case client-side javascript is disabled (and also for the prerendered page before the framework kicks-in)

Steps:

1. Read this to understand what are the requirements for the webpack side of things

   1. Ignore the css-loader?module parameter if you're using angular2: it'll break things because angular2 has built-in style scoping

2. Edit webpack.config.js

   1. Choose one of the two loaders (neither works 100%)

             {
                 test: /\.scss$/,
                 include: /ClientApp/,
                 //loader: "css-loader!sass-loader" // WORKS but not with javascript disabled
                 loader: extractCSS.extract("style-loader", "css-loader!sass-loader") // WORKS but doesn't scope styles
             }

3. Edit node_modules/aspnet-webpack/LoadViaWebpack.js (must do it again if updating the module!)

   1. Remove the client-side loader by adding

         webpackConfig.module = webpackConfig.module || {};
         webpackConfig.module.loaders = webpackConfig.module.loaders || [];
         webpackConfig.module.loaders = webpackConfig.module.loaders.filter(function (loader) {
             return !loader.test.test("style.scss");
         });

   1. Add the new server-side loader by adding

         webpackConfig.module.loaders.push({
             test: /\.scss$/,
             include: /ClientApp/,
             loader: "css-loader/locals!sass-loader"
         });

Hope someone figures out how to make this fully work!

[colltoaction]

It almost works using loaders: ['raw-loader', 'sass-loader'] as suggested in this post, but then you are missing the css-loader and don't get url resolving (e.g. for images).

If you try to use loaders: ['to-string-loader', 'css-loader', 'sass-loader'] or similar you get the Cannot find module './../../node_modules/css-loader/lib/css-base.js' error that was mentioned by @shobman, which I'm pretty sure is an error in the webpack prerendering configuration. I'll take a look later.

[colltoaction]

@SteveSandersonMS @laskoviymishka I know you're not providing a built-in css-preprocessor support, but maybe you could take a look at the issue we're having when doing it ourselves?

The "cannot find module" error looks like a bug in aspnet-webpack because it does work with server-side prerendering disabled. E.g. this works:

<app
     asp-prerender-webpack-config="webpack.config.js">Loading...</app>

Do you want me to open a new issue? Maybe provide a repro? I think you'll hit the issue pretty easily if you try to set up a project with sass, but let me know :).

[SteveSandersonMS]

@tinchou Are you on the current version of Microsoft.AspNetCore.NodeServices? The current version is 1.0.0-beta-000011. Versions prior to beta 10 had an issue around module resolution that might possibly have caused your Cannot find module errors.

I ask this because I just tried setting up a CSS preprocessor (I used LESS), and in all cases it just worked fine. It works both with loader: extractCSS.extract('css!less') to strip out the generated CSS into a regular standalone .css file, and with loaders: ['to-string-loader', 'css-loader', 'less-loader'] (and in component, styles: [require('../../styles/site.less')]) for Angular 2 style encapsulation. I have not experienced any Cannot find module errors in any case.

And if you try to use an array as configuration (allowed by webpack as seen here) you get this exception

I see - thanks for letting me know!

For WebpackDevMiddleware.ts, it does seem reasonable that we could and should support array-style Webpack configurations. It just needs to preprocess them all in the same way, and then return to .NET an array of PublicPath values instead of just one.

For LoadViaWebpack.ts, I don't quite see how it makes sense to support array-style Webpack configurations, unless the developer also has a way of specifying which of their webpack configs is the one they want to use to build this particular file (given that more than one of the configs might be able to build it, possibly in different ways). Maybe if you need this, it would make sense to have each of your configs in separate files, and then combine them into a top-level one like this:

// Top level webpack.config.js
module.exports = [
    require('./webpack.config.first.js'),
    require('./webpack.config.second.js')
];

... and then when using prerendering, you could specify which config you want to use to build the boot module, e.g.:

asp-prerender-webpack-config="webpack.config.second.js"

What do you think?