Skip to content

Simplify SCSS/CSS inclusion in documentation #41743

Closed
MaxLardenois wants to merge 0 commit intotwbs:mainfrom
MaxLardenois:main
Closed

Simplify SCSS/CSS inclusion in documentation #41743
MaxLardenois wants to merge 0 commit intotwbs:mainfrom
MaxLardenois:main

Conversation

@MaxLardenois
Copy link
Contributor

Description

Removes unnecessary code in Head.astro for styles inclusion in dev mode and at build time.

Motivation & Context

First thing this PR is more a discussion as it will not change any behavior or produced code.

In #41574 we differentiated SCSS inclusion in the documentation source between dev mode and prod, in order to permit automated recompilation of SCSS in dev while still using built Bootstrap CSS in prod.
This works well but it might hinge on a side effect of the Astro build versus Vite processing of style resources in dev mode. Indeed it should be noted that, irrespective of their lazy-loading condition, both Scss.astro and ScssProd.astro built CSS are included in dev mode as one can see in the inspector.

Capture d’écran 2025-09-11 à 14 51 02

Conversely the CSS built by astro build command only contains what we want, namely the style for documentation. The conditions on the lazy-load works well in this case.

Capture d’écran 2025-09-15 à 15 29 21

First conclusion: this means that in both modes, the actual presence of <Scss /> or <ScssProd /> in Head.astro do not matter, only the imports are necessary. This PR therefore deletes these and only keeps the lazy-load imports.*

Second conclusion: this discrepancy between astro dev and astro build is maybe not a feature but only a side-effect and might change in the future. This is the main reason for this PR, to document this behavior to have some information if it changes in the future. Maybe the reason behind this is a more "greedy" import strategy in dev mode, in any case I failed to prevent ScssProd.astro style export from being present in this case.

*One could argue keeping the components inside Head.astro template is better from a maintainability point of view, I do not have a strong opinion and would understand if you close this.

Type of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Refactoring (non-breaking change)
  • Breaking change (fix or feature that would change existing functionality)

Checklist

  • I have read the contributing guidelines
  • My code follows the code style of the project (using npm run lint)
  • My change introduces changes to the documentation
  • I have updated the documentation accordingly
  • I have added tests to cover my changes
  • All new and existing tests passed

Live previews

Related issues

@mdo mdo added the docs label Sep 17, 2025
@mdo mdo added this to v5.4.0 Sep 17, 2025
@github-project-automation github-project-automation bot moved this to Needs review in v5.4.0 Sep 17, 2025
@github-project-automation github-project-automation bot moved this from Needs review to Done in v5.4.0 Sep 29, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

2 participants