Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • B bootstrap
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 263
    • Issues 263
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 114
    • Merge requests 114
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Package Registry
    • Infrastructure Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Bootstrap
  • bootstrap
  • Issues
  • #37982
Closed
Open
Issue created Jan 31, 2023 by Administrator@rootContributor2 of 2 checklist items completed2/2 checklist items

Consider defining variables in components' source instead of _variables*.scss

Created by: yugabe

Prerequisites

  • I have searched for duplicate or closed feature requests
  • I have read the contributing guidelines

Proposal

Bootstrap SCSS is good because it is self-explanatory and a way to self-document intent and the code. I suggest for V6 that (default) variable declarations should go into the code that is closest (and scoped) to its use. Although I don't think this will be a breaking change because variables are declared with !default, some users might expect all, even component-specific variables to be defined in _variables.scss and rely on that behavior. So this should be considered a breaking change, possibly a candidate for V6.

This essentially only means that splitting the 72kB _variables.scss across the dozens of components.

Motivation and context

Some pros to consider:

  • The behavior of most apps wouldn't even change, and the users could define their variable overrides however they like. They would only need to define their variables before importing the components themselves -- but this is in line with the current recommendations.
  • Finding how a component can be configured via exposed SCSS variables would be made easier for the users, because if they wish to configure the breadcrumbs, they would only need to look at the _breadcrumbs.scss and see the defined variables at the top of the file.
  • Variables for unused components would not "pollute" the workspace, making the mental load required lower for users, the list of variables in auto-complete/IntelliSense solutions would be lower and possibly a bit faster at development time.
  • The _variables.scss file is by far the largest of all the source files and users are expected to browse it regularly to look up variables. Defining the variables closer to their point of use would help users locate them easier, as well as maintenance easier.

Some very common variables, like $prefix or $spacers might not be specific to components (or even sets of components), so they should probably be kept in _variables.scss (or similar) in the future.

Assignee
Assign to
Time tracking