bootstrap: Missing $primary-text-emphasis-dark variable

Closing as this isn’t a breaking change—minor releases can include new features. This has always been the case in Bootstrap.

ok, if the bootstrap team disagrees and decides to force the people to update their code, that’s fine, it’s a very easy fix, but don’t deny the facts…

In some circumstances, the 5.3.0 update breaks projects running 5.2.3… so yes, it’s a Breaking Change because the update 5.3.0 is not safe to apply… a minor change requirement is broken… The Backwards Compatibility.

References:

• “Backward compatible new features” https://docs.npmjs.com/about-semantic-versioning

• “MINOR version when you add functionality in a backward compatible manner” https://semver.org/#semantic-versioning-200

For people who don’t want to use dark mode: you can also set $enable-dark-mode: false;. Then you don’t have to import bootstrap/scss/variables-dark.

How isn’t this a breaking change? I came here because my build was broken after upgrading. I ended up pinning it to 5.2.3 since importing the dark vars caused other errors and I don’t have time to deal with it yet. Had to pin, since npm install on ^5.2.3 still upgrades to 5.3.0.

Side note: I can’t wait for the dark mode obsession trend to pass Hopefully with something a little more nuanced, say a 50 shades of grey mode 😆

Yes, this should be considered for the next release as it breaks our project if we upgrade to v5.3.0

This is a breaking change actually. I have to change imports in my project.

Haven’t tested it and IDK if it’s something we can actually do; but maybe we could consider moving the content of _variables-dark.scss at the end of _variables.scss (since the Sass var names are all different) surrounded by a @if $enable-dark-mode in a v5.3.1 so that there’s no need to import a new file while migrating. And reintroduce this _variables-dark.scss only for v6.

One other option would be to import _variables-dark.scss at the end of our _variables.scss. Not very consistent with the way we handle Sass files currently we could allow us to keep separate files and limit the breaking change. (Haven’t tried it)

@twbs/css-review thoughts?

As a backend developer trying to ease my life with these libraries but I end up putting on more work with these versions, modules, and all this crap!

@mdo I’m going to reopen a new ticket with the same description as there seems to be a misunderstanding on what “breaking change” means. It should mean: “if you update this library to a new version, all usages of said library should continue to compile.”

Before version 5.3.0, the following code compiles:

@import "bootstrap/scss/functions";
@import "bootstrap/scss/variables";
@import "bootstrap/scss/mixins/breakpoints";

After version 5.3.0, the aforementioned code throws the following error:

HookWebpackError: Module build failed (from ./node_modules/sass-loader/dist/cjs.js):
Undefined variable.
   ╷
55 │     "primary": $primary-text-emphasis-dark,
   │                ^^^^^^^^^^^^^^^^^^^^^^^^^^^
   ╵
  bootstrap\scss\_maps.scss 55:16  @import
  src\styles.scss 19:9             root stylesheet

If you disagree, can you please explain how you and the rest of the Bootstrap team interprets the phrase “breaking change”?

Minor updates have always allowed for new features, and most new features come with new files (e.g., adding toasts). I think having these new ones as separate stylesheets is fine. Maybe there’s more we can do to document the migration?

Minor updates have always allowed for new features, and most new features come with new files (e.g., adding toasts). I think having these new ones as separate stylesheets is fine. Maybe there’s more we can do to document the migration?

The difference here is that the end user can opt into toasts, and not having toasts enabled does not break existing builds. This update broke existing builds, and therefore is a breaking change. It’s not about adding the feature, it’s about the implementation.

To reiterate what was already said - the fix was very straightforward. But shouldn’t have been necessary at all.

Closing as this isn’t a breaking change—minor releases can include new features. This has always been the case in Bootstrap.

Adding a new, entirely optional, feature is completely fine. This here, however, is not the case as additional steps are required to allow builds of existing system to pass, which is the definition of a breaking change. I doubt linux would still be a thing today with this kind of policy on breaking changes, I am saddened to see Bootstrap no longer follow semver.

yeah this is a pretty breaking change if you ask me… gonna throw down on that.

+1

I ran into the same issue. I included the _variables-dark.scss, however, ran into another issue thereafter as shown at #38687.

where and how should I add _variables-dark.scss file?

The documentation at https://getbootstrap.com/docs/5.2/customize/sass, which is source controlled at bootstrap/site/content/docs/5.2/customize /sass.md needs to be updated to reflect this change. I’m chasing my tail because it isn’t working when the official documentation doesn’t mention the dark variables file at all. I’m glad I found the answer, but the docs should be updated so other people don’t continue to make the same mistake.

As a backend developer trying to ease my life with these libraries but I end up putting on more work with these versions, modules, and all this crap!

Lol yes, I have to come to github issue tracker every time I deploy my app now.