Skip to content

Split bootstrap.scss into optional and required counterparts (#22891) - #24802

Closed
steven-pribilinskiy wants to merge 2 commits into
twbs:v4-devfrom
steven-pribilinskiy:v4-split-bootstrap-main-scss
Closed

steven-pribilinskiy wants to merge 2 commits into
twbs:v4-devfrom
steven-pribilinskiy:v4-split-bootstrap-main-scss

Conversation

@steven-pribilinskiy

Copy link
Copy Markdown

Reasons behind this PR are described in #22891

@Johann-S Johann-S added css Sass sources or compiled CSS feature New feature, or a change to how an existing one works v4 v4, the frozen docs on gh-pages labels Nov 16, 2017

@andresgalante andresgalante left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @pribilinskiy thanks for your PR. This is an intresting idea.

I think it adds a layer of unnecessary abstraction and complexity and we end up with the same result, a user would have to choose from the "optional" components anyway.

I rather see a comment on _variables.scss splitting up the settings, files that don't generate code, from the components, that generate code.

It's up to @mdo, but I would pass on this idea.

@XhmikosR

Copy link
Copy Markdown
Member

Yeah, I'd pass on this too.

@steven-pribilinskiy

steven-pribilinskiy commented Nov 16, 2017 •

Copy link
Copy Markdown
Author

It's not an idea, it's a solution to a problem that many could face after switching from LESS to SCSS.

Don't confuse "layers of complexity" with splitting long files (a.k.a spaghetti code).
This solution adds flexibility, provides ability to override variables while reusing (referring to) existing variables that are declared in _variables.scss without the need to copy/paste the whole thing.

In v3 LESS implementation it wasn't an issue to reference an existing variable from variables.less because of lazy variable evaluation. Now in v4, in order to reference an existing variable the _bootstrap.scss must be copied and pasted into project's directory:

// _my-bootstrap.scss
/*
 * Bootstrap v4.0.0-beta.2
 */
@import '~bootstrap/scss/functions';
@import '~bootstrap/scss/variables';
@import 'custom-variables';

@import '~bootstrap/scss/mixins';
@import '~bootstrap/scss/root';
@import '~bootstrap/scss/print';
...

Now after every update one will have to compare the _my-bootstrap.scss file with the _bootstrap.scss and apply the differences because optional components could be added/renamed/deprecated/removed.

we end up with the same result, a user would have to choose from the "optional" components anyway.

Wrong.
The user will be able to easily override the variables by including only two files from node_modules:

@import "~bootstrap/scss/bootstrap-required";
@import "custom-variables";
@import "~bootstrap/scss/bootstrap-optional";

In case of a small project, when there's no need to reference existing variables, the user can go with the old way, leveraging the !default feature.

@import "custom-variables";
@import "~bootstrap/scss/bootstrap";

It will be a win-win solution for any kind of projects

Btw, in the Getting started with theming section of the documentation, there's already a clear separation between Required and Optional stylesheets.

@andresgalante

Copy link
Copy Markdown
Collaborator

@pribilinskiy thanks for the clarification. It'll be up to @mdo if he wants to introduce this reorganization.

@mdo

mdo commented Nov 25, 2017

Copy link
Copy Markdown
Member

Thanks, but we'll pass.

@mdo mdo closed this Nov 25, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

css Sass sources or compiled CSS feature New feature, or a change to how an existing one works v4 v4, the frozen docs on gh-pages

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants