swisspost / design-system

The Swiss Post Design System pattern library for a consistent and accessible user experience across the web platform.
https://design-system.post.ch
Apache License 2.0
113 stars 14 forks source link

can not build client ressources anymore: bootstrap-container definitions maybe need "!default" apendation fix, since design-system-styles v 6.4.2 #3143

Open aedu-hostettler opened 1 month ago

aedu-hostettler commented 1 month ago

Hy Post-Design-System-Team!

I’m struggling with updating the design-system-styles component above version 6.4.1. (6.4.1. still works, but 6.4.2 or up to current 7.1.0 does not work anymore.) It has to do with a change/override at the container component of bootstrap.

Context of our setup: We use following components successfully:

    "@swisspost/design-system-components": "7.0.0",
    "@swisspost/design-system-icons": "7.0.0",
    "@swisspost/design-system-styles": "6.4.1",
    "@swisspost/internet-header": "1.9.1",

If we want to update the “internet-header”, (and thus by new dependencies/versioning all other packages), it has a new internal dependency to “design-system-styles” 7.1.0. To make the design-system-styles 7.1.0 running, we also had to add manually the dependency "@stencil/core": "4.18.3", Because it wasn’t available/resolvable within the design-system-styles package itself. (at least, that was, what our webpack-builder was noting)

We also add our own bootstrap package in addition to your design-system-packages. (We use your styles, but also have our own overridden definitions, based, on the original bootstrap (5.3.3.) definitions.)

The following error makes it impossible for us to build our definitions anymore. The “container” change after design-system-styles 6.4.1 makes it impossible to override the container definitions again.


[./node_modules/@stencil/core/internal/app-data/index.js](./node_modules/@stencil/core/internal/app-data/index.js) 2.51 KiB   
[./node_modules/@stencil/core/internal/client/](./node_modules/@stencil/core/internal/client/) lazy ^\.\/.*\.entry\.js.*
$ include...(truncated) 160 bytes Module build From line 30, column 13 of node_modules\bootstrap\scss\_containers.scss:    
╷30 │             @extend %responsive-container-#{$breakpoint};   │             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^   
╵You may not @extend selectors across media queries.

I was wondering, if you could define your container related overrides with a !default apendation, so they could be overridden again at a later compiling-stage, e.g. by the original bootstrap or our own definitions.

Example for form-switch definitions, we had to override with !default definitions, so the original bootstrap behaviour was still working. But this way, on special circumstances, we could still override the default behaviour later:

$form-switch-width: 2em !default;
$form-switch-height: 1em !default;
$form-switch-padding-start: $form-switch-width + .5em !default;
$form-switch-border-radius: $form-switch-width !default;
$form-switch-transition: background-position .15s ease-in-out !default;
$form-switch-unchecked-bg-position: left center !default;
$form-switch-checked-bg-position: right center !default;

Is it somehow possible to use !default definitions on the container definitions/breakpoint definitions/overrides, so we can still override them again, if needed?

Not sure, if this would be a solution, but it would be nice, if we could still override your definitions with our own bootstrap-based definitions, otherwise, we would have to change so much on our several web-portals, if we only want to use your design-system, without using our own bootstrap-based controls. (we need native bootstrap functionality for other things too.)

Greetings

Adrian

gfellerph commented 1 month ago

Hey @aedu-hostettler, thanks for submitting this issue. Out of interest, what are you overriding the container styles with? What are your requiremenets for containers? We'll have a look at the request and update as soon as possible.

aedu-hostettler commented 1 month ago

Hy @gfellerph.

We override it with the default bootstrap definitions (currently 5.3.3) actually. We need the normal bootstrap functionality for non-angular websites. Maybe there are even more issues regarding building bootstrap with design-system-styles, meaning there could be more issues than just the container topic.

With Design System v 6.4.1. (and before) we can build client-bundle ressources where the design-system-styles and native bootstrap (with some sass overriden variables from our side) both work in conjunction at the same time. But with version 6.4.2. and newer, we are not able to build the client ressources anymore.

I know, it seems silly to override/use in parallel a bootstrap-based lib with original bootstrap again, but we need the bootstrap default lib behaviour to show some tooltips or popovers and also to show modals etc.

Our "ecosystem" was built from the ground up with our own bootstrap and own "new post-designs" before the post-design-system existed. We use every (non-angular-)design-system-component/layout/styles/icons we can from you, but still need our own bootstrap/popper/calendar (tempus dominus)/jquery(+ui) instances for functionality and backwards compatibility.

Should i provide you all the client related ressources we need? Package.json, css and scss files, js, webpack dev and prod scripts? Or would this already be enough (part of package.json)

    "@swisspost/design-system-components": "7.1.0",
    "@swisspost/design-system-icons": "7.1.0",
    "@swisspost/design-system-styles": "6.4.1",
    "@swisspost/internet-header": "1.13.10",
    "bootstrap": "5.3.3",

"@swisspost/design-system-styles": "6.4.1", -> can bundle all client ressources, no conflict "@swisspost/design-system-styles": "6.4.2", -> conflict with native bootstrap lib up to "@swisspost/design-system-styles": "7.1.0", -> conflict with native bootstrap lib

This would be an excerpt of our scss definitions:

@import "mixins/_mixins.scss";
@import '../../node_modules/jquery-ui/dist/themes/base/jquery-ui.css';
@import '../../node_modules/@eonasdan/tempus-dominus/dist/css/tempus-dominus.css';
@import '../../node_modules/@swisspost/internet-header/dist/swisspost-internet-header/swisspost-internet-header.css';
@import "../non_npm_libraries/flying-focus/_flying-focus.scss";
@import "fonts/_fonts.scss";

//then we override some bootstrap variables, before we import bootstrap and design-system-styles later within #glaux-page-content (div-id, that is between post-internet-header and footer, so our definitions would not override/influence your header/footer definitions) (for brevity the variables are not listed here)
//the overriden variables will influence the bootstrap.scss that is imported later.
//See possible available variables to override in /node_modules/bootstrap/scss/_variables.scss

#glaux-page-content {
    @import "../../node_modules/bootstrap/scss/bootstrap.scss";
    @import "../../node_modules/@swisspost/design-system-styles";
...... custom scss/css definitions cut out for brevity
}

Webpack can no longer build both besides each other since design-system-styles 6.4.2. For clarity, we do not need special container definitions. Webpack (or more specific sass-loader) just cant handle the default bootstrap definitions besides the design-system-styles definitions anymore. Also it does not matter, if i import first bootstrap, and then design-system-styles, or vice-versa.

Again the full error message from building the ressources:

ERROR in ./SourceJsCss/scss/style2019.scss (./SourceJsCss/scss/style2019.scss.webpack[javascript/auto]!=!./node_modules/css-loader/dist/cjs.js!./node_modules/postcss-loader/dist/cjs.js??ruleSet[1].rules[0].use[2]!./node_modules/sass-loader/dist/cjs.js??ruleSet[1].rules[0].use[3]!./SourceJsCss/scss/style2019.scss)
failed (from ./node_modules/sass-loader/dist/cjs.js):
ERROR in ./SourceJsCss/scss/style2019.scss
failed (from ./node_modules/mini-css-extract-plugin/dist/loader.js):
failed (from ./node_modules/sass-loader/dist/cjs.js):
error --
Error: Module build failed (from ./node_modules/sass-loader/dist/cjs.js):
Error("Module build failed (from ./node_modules/sass-loader/dist/cjs.js):\nFrom line 30, column 13 of node_modules\\bootstrap\\scss\\_containers.scss: \n   ╷\n30 │             @extend %responsive-container-#{$breakpoint};\n   │             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n   ╵\nYou may not @extend selectors across media queries.\n   ╷\n30 │             @extend %responsive-container-#{$breakpoint};\n   │             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n   ╵\n  node_modules\\bootstrap\\scss\\_containers.scss 30:13  @import\n  SourceJsCss\\scss\\style2019.scss 204:13              root stylesheet");
2 errors in 14575 ms

If you need more information, or when you need some kind of playground/all ressources from me, let me know.

Greets, Adrian

aedu-hostettler commented 1 month ago

Hy @gfellerph.

I created 2 stackblitz playgrounds, so you could see a working example with v 6.4.1 and a non buildable example with v 7.1.0.

https://stackblitz.com/edit/stackblitz-bootstrap-design-system-styles-641

https://stackblitz.com/edit/stackblitz-bootstrap-design-system-styles-710

The preview on 6.4.1 shows working components, the preview on 7.1.0 shows the compiling error message.

Maybe like this you could try to test successfull building with your custom npm versions?

Hope this helps. I also removed all the unneeded devDependencies from the stackblitz projects, so only the libs are in the project, that are related to the problem.

Cheers, Adrian ps: we don't use vite on our environment. i only used vite within the stackblitz as prototyping-dependency. (but the compiling error message is the same)