CSS and SCSS Bundling with Parcel Quiz Quiz

Explore key concepts of CSS and SCSS bundling using Parcel, including configuration, file imports, and optimizing stylesheets for efficient web development. This quiz is designed to help you assess and strengthen your understanding of bundling workflows, preprocessors, and common troubleshooting scenarios.

  1. Importing Stylesheets in Entry Files

    When using Parcel to bundle your project, how should you import a main SCSS file into your JavaScript entry file for the styles to be included in the build?

    1. import './styles/main.scss';
    2. require('./styles/main.sass');
    3. @import './styles/main.scss';
    4. styles.main.sass()

    Explanation: The correct approach is to use import './styles/main.scss'; in your JavaScript entry file to ensure Parcel recognizes and processes the SCSS during bundling. Using @import is the SCSS file syntax, not a JavaScript import statement. require('./styles/main.sass'); is Node's CommonJS syntax, which is less common and may cause issues in ESM settings. styles.main.sass() is not a valid method for importing styles.

  2. Handling SCSS Variables and Nesting

    Suppose your styles use SCSS variables and nested selectors; what must Parcel do by default to correctly output styles in the browser?

    1. Automatically compile SCSS to standard CSS before bundling
    2. Require manual conversion of SCSS to CSS from the user
    3. Leave SCSS syntax unchanged in the final bundle
    4. Convert SCSS to LESS, then bundle the LESS file

    Explanation: Parcel automatically compiles SCSS to standard CSS as part of its build process, enabling browsers to correctly interpret the final output. Converting SCSS to LESS is not necessary and not a default behavior. Leaving SCSS syntax untouched would result in styles not being recognized by browsers. Manual conversion is not required when using Parcel, as the process is automated.

  3. Resolving File Import Errors

    If you receive an error about a missing dependency when importing an SCSS file, which step is most likely to resolve the issue?

    1. Change the file extension from .scss to .css
    2. Delete your entry JavaScript file
    3. Remove all @import statements from SCSS files
    4. Install the appropriate SCSS compiler dependency

    Explanation: The most common solution is installing the necessary SCSS compiler dependency, allowing Parcel to process SCSS files. Changing the extension to .css disables the use of SCSS features. Deleting your JavaScript entry file does not address dependency issues. Removing all @import statements may break your styles and is unnecessary if the compiler is missing.

  4. Optimizing Output with Bundling

    When bundling CSS and SCSS for production, which benefit does Parcel provide by default?

    1. Separates each imported CSS file into its own output file
    2. Automatically minifies and combines stylesheets into a single optimized file
    3. Converts all CSS to inline styles in HTML files
    4. Ignores style dependencies and only processes JavaScript

    Explanation: Parcel's default production mode optimizes stylesheets by minifying and combining them, improving load times. Separating files contradicts the purpose of bundling and optimization. Ignoring style dependencies would cause missing styles in the output. Converting all CSS to inline styles is not the default behavior and is generally handled differently.

  5. Using SCSS Partials Effectively

    In a Parcel setup, which technique allows the reuse of variables and mixins across several SCSS files without duplicating code?

    1. Using HTML u003Cstyleu003E elements for every variable definition
    2. Renaming SCSS files to .css so they share CSS rules
    3. Declaring variables in every individual SCSS file
    4. Creating SCSS partials with names beginning with an underscore and importing them

    Explanation: SCSS partials, named with a leading underscore, enable code reuse when imported into other SCSS files, making the codebase more maintainable. Using HTML u003Cstyleu003E elements does not share SCSS variables. Declaring variables in every file leads to redundancy and is not efficient. Renaming files to .css removes access to SCSS features like variables and mixins.