This page needs a newer browser to run its tools. You can still read everything here.

CSS Module 19

Sass modules, migrating off @import and Sass in production interview questions

Interview questions on sass modules, migrating off @import and Sass in production: warm-ups, then what each harder question tests and how a good answer starts.

9 questions: 3 warm-ups and 6 with model answers · Levels: Fresher to senior

Warm-up questions

Short questions with short answers, each answered in full.

Fresher to mid

What is the difference between @use and @import in Sass?

Answered in the lesson Sass modules: @use, @forward and configuration
Fresher to mid

Why is Sass deprecating @import, and when will it stop working?

Answered in the lesson Migrating Sass from @import to modules
Fresher to mid

When would you still choose Sass over native CSS today?

Answered in the lesson Sass in production and when to use native CSS

Questions with model answers

What each question tests, the first step of a good answer and the follow-ups to expect.

Mid to senior

Twelve product teams load your design system's Sass with @use "ds" as *, and several of them call helpers you never meant to publish. A release renamed one helper and broke four apps. How would you make the library's public API explicit, and how would you roll the change out without breaking the teams again?
What it tests

Designing a Sass module API with an index file, show and hide, prefixes and private members, and changing a shared library safely with deprecation warnings and semantic versioning.

First step

Find out what the apps use today: compile each one against the library and list the members it reaches, or search their sources for the library's names. That list is the public API. Everything else becomes private, with a leading - in its file, or package-private, hidden from the index, and the index forwards the public members with explicit show lists.
Follow-ups
- Why does as * make this worse, and what would you ask the teams to do?
- How do you keep a renamed member working for one more release?
- When do you choose a private member over a package-private one?
From the lesson Sass modules: @use, @forward and configuration
Model answer, Pro. Model answers open with any pass; prices are in the notice on this page.
Opening the model answers with your pass…
Model answers open with any MySmartCoPilot pass.
Pro pass · 1 week₹79$2.99
30 days₹179$5.99
1 year₹1,699$45
One payment; nothing renews unless you choose to. The price shown is the total you pay: no fees or charges are added at checkout.
Passes can’t be bought right now, so the model answers can’t be opened at the moment. If you have a pass, enter your licence key.
Choose a pass I have a licence key
It also opens every other in-depth part in Learn and every Pro tool. Sales are final, except where the law gives you a right to withdraw, for example in the EU and the UK (refund policy).
In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 4 minutes
Mid to senior

Your build needs a light and a dark stylesheet from one Sass library. A teammate loads the library twice in one entry file with two with clauses and gets "This module was already loaded, so it can't be configured using with". Explain the error, design two setups that work, and say which you would ship.
What it tests

One configuration per module and compilation, theming with separate entry points against CSS custom properties, and choosing by when the theme is decided.

First step

Explain the rule first: Sass evaluates a module once per compilation and fixes its configuration at the first load, so a second with clause has nothing left to configure. Then ask when the theme is chosen, when the site is built or while the page is open, because that decides between two compilations and custom properties.
Follow-ups
- What does each setup cost in CSS size and requests?
- How do the components read the theme in the custom-property setup?
- Could meta.load() with $with load the library a second time in the same compilation?
From the lesson Sass modules: @use, @forward and configuration
Model answer, Pro.
In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 4 minutes
Mid to senior

A 300-file Sass codebase prints over 2,000 deprecation warnings per build, most of them from a vendored framework. Plan a migration that blocks new deprecated code from the first day while the team migrates over several sprints, and say how you would prove that each step changed no CSS.
What it tests

Separating your warnings from a dependency's, quietDeps and fatal deprecations in CI, staged sass-migrator runs, byte comparison against a pinned baseline, and planning the work across a team.

First step

Measure before changing anything: compile every entry point in verbose mode with a logger that counts warnings by deprecation ID and by origin, your files against the vendored ones. Pin the Sass version and keep the compiled CSS of every entry point as the baseline. That gives the real size of the job and a way to prove each step.
Follow-ups
- How do you fail CI on new deprecated code while thousands of old warnings remain?
- Which migrations do you run first, and why?
- What do you do about the vendored framework?
From the lesson Migrating Sass from @import to modules
Model answer, Pro.
In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 4 minutes
Mid to senior

After a migration to @use, the compiled CSS differs from the baseline by a handful of lines. How do you find out whether the migration caused it, and which behaviours of the module system can change the output on their own?
What it tests

Debugging a migration with diffs and replays, version pinning, and the module-system behaviours that change output: extend scope, meta.load-css() and parent selectors, configuration order, and colour functions.

First step

Rule out the toolchain first: check that the baseline and the new build used the same Sass version and the same output style, then expand both files and diff them. Trace each changed rule to its source file, and replay the migration one step at a time against the baseline to find the step that introduced the change.
Follow-ups
- Why can an @extend change or fail after the migration?
- Could a colour change come from the migration itself?
- How would you stop this from happening on the next codebase?
From the lesson Migrating Sass from @import to modules
Model answer, Pro.
In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 4 minutes
Mid to senior

A Vite project compiles 140 SCSS entry files, the CSS step takes most of a slow CI build, and the team wants it faster. What do you measure first, and what would you change, in what order?
What it tests

Which Sass package Vite loads, the async and sync APIs, duplicated work through additionalData and repeated framework compiles, and proving a speed-up with measurements.

First step

Measure before changing anything: check which Sass package Vite actually loads, time a cold build and the CSS step on its own, and count how often the heavy stylesheets, such as a framework or a token module, are compiled across the 140 entry files. The largest cost decides the first change.
Follow-ups
- Why does installing sass-embedded make so much difference in Vite?
- How can additionalData make a build slower and its CSS larger?
- How would you prove that the change made the build faster?
From the lesson Sass in production and when to use native CSS
Model answer, Pro.
In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 3 minutes
Mid to senior

A dependency update moves Sass from 1.78.0 to 1.105.1, and the compressed CSS of your customised Bootstrap grows by about 5 KB with no change to your source. How do you decide whether the update is safe to ship?
What it tests

Pinning and isolating compiler upgrades, diffing expanded output, telling serialisation changes from changes in meaning, and testing the risky kinds in browsers.

First step

Isolate the change: one commit that only moves the Sass version, then compile with both versions in the same output style, expand both files and diff them. Sort every changed line by kind, such as a colour written another way or a changed value, before judging any of them.
Follow-ups
- Why did the CSS grow if the colours did not change?
- Which of the changes would you check in a browser, and how?
- How do you stop compiler upgrades from arriving by surprise?
From the lesson Sass in production and when to use native CSS
Model answer, Pro.
In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 3 minutes

All CSS interview questions · The CSS track

Warm-up questions

What is the difference between @use and @import in Sass?

Why is Sass deprecating @import, and when will it stop working?

When would you still choose Sass over native CSS today?

Questions with model answers

A 300-file Sass codebase prints over 2,000 deprecation warnings per build, most of them from a vendored framework. Plan a migration that blocks new deprecated code from the first day while the team migrates over several sprints, and say how you would prove that each step changed no CSS.

After a migration to @use, the compiled CSS differs from the baseline by a handful of lines. How do you find out whether the migration caused it, and which behaviours of the module system can change the output on their own?

A Vite project compiles 140 SCSS entry files, the CSS step takes most of a slow CI build, and the team wants it faster. What do you measure first, and what would you change, in what order?

A dependency update moves Sass from 1.78.0 to 1.105.1, and the compressed CSS of your customised Bootstrap grows by about 5 KB with no change to your source. How do you decide whether the update is safe to ship?