Feature Request: Support Custom CSS Directory in Quasar Configuration

[maximilianfixl]

Hello Quasar Team,

I am currently working on a project where I am reorganizing the structure to follow SOLID and Domain-Driven Design (DDD) principles. As part of this reorganization, I aim to move the CSS files into a dedicated directory within the interface layer of the project. This aligns with the separation of concerns and the overall architecture.

Currently, I have encountered an issue where it seems that Quasar (newest @quasar/app-vite v2) expects CSS files to reside in the default src/css/ directory. While I can load app.scss successfully from another location, the imports within the SCSS files (e.g., @import "quasar.variables.scss";) are ignored. This limitation makes it difficult to move the CSS files to a different directory while maintaining Quasar's expected behavior.

Current Situation:

1. CSS files outside the default src/css/ directory are not handled as expected.
2. SCSS imports such as @import "quasar.variables.scss"; fail unless the files remain in the default directory.
3. If I define a custom path for app.scss in quasar.config.ts, the path is incorrectly appended to src/css/.
   Example: If I configure css: ['src/ui/css/app.scss'], it becomes src/css/src/ui/css/app.scss internally.
   To bypass this, I need to use relative paths like ./../../src/css/app.scss, which feels hacky and causes SCSS imports to stop working.
4. There seems to be no straightforward way to define a custom CSS directory in the quasar.config.ts file, similar to how sourceFiles can be configured.

Proposed Feature:

Introduce a configuration option in quasar.config.ts that allows developers to define a custom directory for CSS files. This could work similarly to the sourceFiles configuration, where the root CSS directory can be redefined.

Example:

build: {
  sourceFiles: {
    rootStyles: 'src/ui/css', // Allow relocating CSS files within rootStyles or rootCss
  }
},
css: [
    'app.scss' // This would be src/ui/css/app.scss
]

Why This Feature Matters:

• Improved Flexibility: Allows developers to align the CSS structure with architectural principles like SOLID and DDD, where CSS files may belong to a specific layer (e.g., the interface layer).
• Project Organization: Supports custom project structures, making Quasar more adaptable to various organizational needs.
• Consistency: Provides a more elegant solution for handling custom CSS paths without requiring workarounds.

Thank you for considering this feature request! I believe it would benefit many developers looking for flexibility in organizing their projects. 🚀

Best regards,

Max

[hinogi]

quasar/app-vite/lib/quasar-config-file.js

Lines 649 to 654 in d26cc6b

	if (cfg.css.length > 0) {
	cfg.css = cfg.css.filter(_ => _)
	.map(parseAssetProperty('src/css'))
	.filter(asset => asset.path)
	.filter(uniquePathFilter)
	}

This seems to always add src/css if the path is not already starting with src/css with the single exception of ~. UNLESS the path is not a string

quasar/app-vite/lib/quasar-config-file.js

Lines 87 to 102 in d26cc6b

	function parseAssetProperty (prefix) {
	return asset => {
	if (typeof asset === 'string') {
	return {
	path: asset[ 0 ] === '~' ? asset.substring(1) : prefix + `/${ asset }`
	}
	}
	return {
	...asset,
	path: typeof asset.path === 'string'
	? (asset.path[ 0 ] === '~' ? asset.path.substring(1) : prefix + `/${ asset.path }`)
	: asset.path
	}
	}
	}

it seems that you can enter something that is not a string and has a property path that is also not a string to circumvent the behaviour

[hinogi]

{
  path: () => 'src/ui/css'
}

just a guess

[hinogi]

no idea how it will be further processed though

[maximilianfixl]

Hi @hinogi,

thank you for your feedback and the approach of solving it with a function. It would indeed have been an acceptable workaround.
Unfortunately, the typing of the ConfigureCallback does not fit at this point, so that a warning of the return type is generated..

Caution

Argument of type is not assignable to parameter of type ConfigureCallback

The expected return value of the css property is currently string[]. This definition can be found in conf.d.

/**
* Global CSS/Stylus/SCSS/SASS/... files from `/src/css/`,
* except for theme files, which are included by default.
*/
css?: string[];

Nevertheless, thank you for your suggestion to solve it this way. At this point, there is still a dependency on the framework, which is not a problem at all for the general use case.
For large applications, however, it becomes somewhat difficult at this point if you want to have all the advantages of the framework but at the same time all the flexibility. 🔄️

[maximilianfixl]

Update (from Discord channel)

🌏 Discord feed in #ideas channel

I’ve managed to make it work by moving the entire css folder (in our case into src/ui/css).
It’s still just a workaround, but it allows us to keep a clean architecture for now.

By default, Quasar forces everything in css: [] through the src/css path.
With this little trick we “get Quasar off the src/css route” (with documented ~) and let Vite handle it instead – which gives us the desired behavior.

The workaround only requires changes in quasar.config.ts:

css: [
  '~@ui-css/index.scss',
  '~@quasar/quasar-ui-qcalendar/src/index.scss',
]

Then configure Vite to resolve the alias:

extendViteConf(viteConf) {
  viteConf.resolve ??= {}
  viteConf.resolve.alias ??= {}
  Object.assign(viteConf.resolve.alias, {
    '@ui-css': '/src/ui/css',
  })
}

So far this works fine, but it’s clearly just a Vite workaround.
Native support for configurable CSS paths in Quasar would make this much cleaner 🚀

---

/src
  ├ /boot  # Quasar boot files, startup logic
  │   └─ ...   # e.g. i18n, apollo, pinia, router setup
  │
  ├ /application   # Application layer (UseCases, services)
  │   └─ ...
  │
  ├ /domain  # Pure domain logic: entities, value objects, events
  │   └─ ...
  │
  ├ /infrastructure  # Interfaces to DB, APIs, external services
  │   └─ ...
  │
  ├ /ui  # Presentation layer
  │   ├─ /components  # Vue components
  │   ├─ /pages  # Page components
  │   ├─ /layouts  # Layout components
  │   ├─ /css  # Styles moved here (instead of src/css)
  │   └─ ...
  │
  ├ /shared  # Shared utilities, types, composables, constants
  │   └─ ...
  │
  └─ quasar.config.ts  # Quasar config

Benefits of this structure
• Clear separation of layers (DDD / SOLID) → domain stays independent, UI stays “dumb”.
• boot as its own folder → makes sense, since it’s only startup logic (and Quasar supports this out of the box).
• ui/css → with the workaround, styles now live properly in the presentation layer, instead of cluttering src/css.
• shared → holds anything reused across layers (types, utils, composables).