Consider including the SCSS files in the bundle

[shlomiassaf]

@jelbourn

Up until recent release, the SCSS files were shipped with the npm bundle.

We have are requirement for some heavy CSS restyling of the components to fit the company guideline. With some components it was not possible via class override, on those it was possible it looked terrible and unmaintainable, lots of css hacks.

We built a webpack loader that uses AST to visit all decorator styles properties and replace them with a recompiled SCSS. The SCSS got compiled after we changed some $variables and our SCSS file @imported the original material SCSS file of the component restyled.

It worked fine, but now we don't have access to the SCSS files through the npm package, we have to get the whole git as a submodule which is something I would rather not do.

Will you guys consider adding the SCSS files to the bundle?

[hansregeer]

+1
Same request here. We use the material2 components for all basic interaction elements. But there are some specifically styled elements in the app that make no sense to inherit from some material2 component.

But we want to achieve consistency in the design and all material of the app, so we use as much of the mixins like mat-elevation() in our own SCSS files.

Is there a way to extract mixins in the build process and ship a _mixins.scss with the npm bundle? To prevent deeplinking?

[xtianus79]

+1 overriding everything is not best practice

[jelbourn]

I chatted with Igor about this and ultimately we decided that the npm package exists to publish the build artifacts and that the scss files are considered source code. As such, GitHub would be the most appropriate place to get those source files for that level of customization in downstream apps.

[xtianus79]

@jelbourn @IgorMinar I understand the build is to publish artifacts. However, like bootstrap, overriding everything is not good design practice. When someone gives me a psd and says, "build this like the mockup," I will then have to override override override everywhere. My root level scss file is a global override directive. Furthermore, like Foundation (which I love), there may be portions of the css I have no interest and want to ex that out of the code base.

I would beg for you guys to perhaps think about this again and at least give the option because in a design sense it is difficult to surmise this as being best practice.

[lqc]

@jelbourn What about 3rd-party projects that just want to reuse the SCSS mixins? We're not customizing anything, but rather create our own components that we want to be inline with Angular Material. Reimplementing them would not be very DRY.

The argument about "source code" is a little weird for a project that uses TypeScript. It's like you published only JS files in the bundle because TS is source code and not an artifact.

[willshowell]

@hansregeer mat-elevation() is exposed in @angular/material/theming as are ~85% of the other mixins

[xtianus79]

@willshowell mixins are ok/great but still provide bloat over settings and params

[Maximaximum]

Very pity you don't ship scss variables within the npm bundle. I'm trying to create my own custom components that would look and feel like angular material, but in order to do that I have to redeclare a whole lot of scss variables.

Seems weird since you do export the Typescript declaration files.

[Maximaximum]

It's a pity that this hasn't been revised.

For example, now I need to use the theme-defined colors in my app (I need to apply the warning color to a custom component).

Is this totally impossible (without redeclaring the variable in my scss files), or am I missing something?