Webpack with CSS Preprocessors (Sass/Less) Quiz Quiz

Challenge your understanding of configuring Webpack to work efficiently with CSS preprocessors like Sass and Less. This quiz covers loader setup, source maps, file management, and optimization best practices for modern web development workflows.

  1. Loader Configuration for Sass

    Which sequence of Webpack loaders is typically required to compile and inject Sass (.scss) files into your project, ensuring styles are rendered in the browser?

    1. css-loader, style-loader, sass-loader
    2. sass-loader, style-loader, css-loader
    3. sass-loader, css-loader, style-loader
    4. style-loader, css-loader, sass-loader

    Explanation: The correct sequence is style-loader, css-loader, sass-loader, as loaders are applied from right to left: sass-loader compiles Sass to CSS, css-loader processes CSS imports, and style-loader injects styles. The sequence 'sass-loader, style-loader, css-loader' is incorrect because the intermediate CSS is not handled properly. 'css-loader, style-loader, sass-loader' puts style-loader before the conversion, which won't work. 'sass-loader, css-loader, style-loader' also puts style-loader at the end, which is not the intended usage.

  2. Source Maps with Preprocessors

    How can you ensure accurate source maps are generated when using Webpack to process Less files for easier debugging in development?

    1. Enable sourceMap options in both less-loader and css-loader
    2. Add a resolveSourceMap property to less-loader
    3. Set 'inline' mode in less-loader only
    4. Only use devtool: 'inline-source-map' in Webpack config

    Explanation: Accurate source maps require enabling sourceMap options in both less-loader and css-loader since both transformations can affect source locations. Setting 'inline' mode in less-loader alone is insufficient as css-loader also modifies the output. Relying just on devtool: 'inline-source-map' helps, but not activating loader-specific options may produce incorrect mappings. There is no valid resolveSourceMap property for less-loader, making that option incorrect.

  3. Handling Imports in Preprocessed Files

    When importing partial files (e.g., _variables.scss) in your main Sass file, what must be considered in your Webpack configuration for these imports to work automatically?

    1. Only use the import-loader before sass-loader
    2. Define all partials in the entry array
    3. Add file-loader after sass-loader
    4. Ensure includePaths in sass-loader cover relevant directories

    Explanation: Setting includePaths in sass-loader allows Sass to locate and import partials from custom directories seamlessly. The import-loader is unrelated to Sass file imports and is used for JavaScript imports. Adding file-loader is not necessary for processing Sass imports, as it handles asset files instead. Defining all partials in the entry array is unnecessary because partials are included through Sass syntax, not separately in Webpack's entry.

  4. Optimizing Production Builds

    Which Webpack loader or plugin is most appropriate for extracting compiled CSS from Sass or Less files into separate CSS files for better browser caching in production?

    1. less-loader
    2. style-loader
    3. mini-css-extract-plugin
    4. sass-resource-loader

    Explanation: Using mini-css-extract-plugin is the typical approach to extracting compiled CSS into standalone files for optimized production builds with improved caching. less-loader and sass-resource-loader are for transforming styles, not extracting files. style-loader injects styles into the DOM but does not create separate CSS files, making it unsuitable for production optimization in this context.

  5. Variable Conflicts and Scoping

    In the context of using Sass or Less with Webpack, what is the result if two files define the same variable name and are imported into the same stylesheet?

    1. Only the first variable definition will be used throughout
    2. Webpack will throw a compilation error due to naming conflict
    3. The last imported variable definition will overwrite the previous one
    4. Both variable definitions will coexist without conflict

    Explanation: When two Sass or Less files define the same variable and are both imported, the last import overwrites the previous value since variables are globally scoped by default. They do not coexist without conflict, and Webpack does not throw an error for overwriting variables. The statement that only the first definition is used is incorrect because later imports take precedence.