Quasar variables are undefined if use @use instead of @import in app.scss file

What happened?

If try to split app.scss into smaller files and use them in the app.scss with @use sass partials, you will get an error if you have used any quasar sass variable in it. Is there any way to include them with @use and access quasar variables or do we have to use @import?

What did you expect to happen?

I expect to have access to Quasar variables if I use @use sass partials.

Reproduction URL

https://codesandbox.io/s/polished-shadow-nc5gjs?file=/src/css/app.sass

How to reproduce?

1. create q project with Quasar CLI
2. add a _dark.theme.sass file in CSS folder
3. include _dark.theme.sass file in app.sass file with @use ‘dark.them’

Flavour

Quasar CLI (@quasar/cli | @quasar/app)

Areas

Quasar CLI Commands/Configuration (@quasar/cli | @quasar/app), Style & Identity (quasar)

Platforms/Browsers

No response

Quasar info output

Operating System - Windows_NT(10.0.19042) - win32/x64
NodeJs - 14.17.5

Global packages
  NPM - 7.21.0
  yarn - 1.22.4
  @quasar/cli - 1.0.5
  @quasar/icongenie - 2.3.1
  cordova - 9.0.0 (cordova-lib@9.0.1)

Important local packages
  quasar - 2.5.4 -- Build high-performance VueJS user interfaces (SPA, PWA, SSR, Mobile and Desktop) in record time
  @quasar/app - 3.3.2 -- Quasar Framework local CLI
  @quasar/extras - 1.12.5 -- Quasar Framework fonts, icons and animations
  eslint-plugin-quasar - Not installed
  vue - 3.2.30 -- The progressive JavaScript framework for building modern web UI.
  vue-router - 4.0.12
  vuex - 4.0.2 -- state management for Vue.js
  electron - Not installed
  electron-packager - Not installed
  electron-builder - Not installed
  @babel/core - 7.17.2 -- Babel compiler core.
  webpack - 5.68.0 -- Packs CommonJs/AMD modules for the browser. Allows to split your codebase into multiple bundles, which can be loaded on demand. Support loaders to preprocess files, i.e. json, jsx, es7, css, less, ... and your custom stuff.
  webpack-dev-server - 4.7.3 -- Serves a webpack app. Updates the browser on changes.
  workbox-webpack-plugin - Not installed
  register-service-worker - 1.7.2 -- Script for registering service worker, with hooks
  typescript - 4.5.5 -- TypeScript is a language for application scale JavaScript development
  @capacitor/core - Not installed
  @capacitor/cli - Not installed
  @capacitor/android - Not installed
  @capacitor/ios - Not installed

Quasar App Extensions
  *None installed*

Networking
  Host - it-korevli-pc
  vEthernet (Default Switch) - 172.22.176.1
  Ethernet - 192.168.0.92

Relevant log output

No response

Additional context

No response

[Noxdor]

Why not @import them? It’s essentially the same for your use case. Unfortunately, we can’t enhance this specific case for @use unless we start parsing scss ourselves, resulting in MASSIVE overhead and noticeable downgraded compile performance.

@import has a number of problems in comparison to @use and will eventually be removed from the language all together. By that, writing code with @import will result in deprecated code in the future. See the SASS documentation for further details.

Hence this is not a small issue - in my opinion - since it is about future-proofing this framework for the use of sass in the coming years and enabling loved and used sass features like scoping that become possible with @use.

[rstoenescu]

@import will work just fine. It’s not like @use is not supported - yes, you can use it, just that we can’t auto-inject the variables in such a case.

From an outside perspective, it’s easy to say the above. However, the changes and deprecations that the Sass team have done in a minor release would involve the mother of breaking changes for Quasar v2 to adapt to, which is not something that the vast majority of our developers would enjoy. How would you feel upgrading Quasar to a newer minor version and suddenly your app is broken unless you do required changes to your code? Hence this is already planned for Quasar v3.

However, should you really want this to work, you’ll need to do it manually. In your imported file (with @use) add this at the top:

@import '...path/to/your/quasar.variables.sass', 'quasar/src/css/variables.sass'

Replace ...path/to/your/ to the relative path from the file to your /src/css/quasar.variables.sass. For https://codesandbox.io/s/polished-shadow-nc5gjs?file=/src/css/app.sass this would mean editing _dark.theme.sass to include this at the very top:

@import './quasar.variables.sass', 'quasar/src/css/variables.sass'

Why is this manual thing needed? Because from the CLI we only have access to the first file (app.sass). It’s then passed to the Sass compiler so any other import/use are handled by Sass itself recursively (without our CLI knowing about which such files are loaded). We cannot inject code into the Sass compiler to auto-import “stuff”.