🚀 feature request

It would be nice if the example's styles.css showed how to import something like

@import '~@angular/material/theming';

https://material.angular.io/guide/theming-your-components

Relevant Rules

This may be better as a rules_sass feature request.

Describe alternatives you've considered

I couldn't figure out how to depend on the material scss files, so I just vendored them and made a sass_library myself.

This is the approach I took:

BUILD

sass_library(
    name = "angular_material_theming",
    srcs = [
        "@npm//:node_modules/@angular/material/_theming.scss",
    ]
)

sass_binary(
    name = "global_app_styles",
    src = "styles.scss",
    deps = [
        ":app_theme",
        ":angular_material_theming",
        "//some/other/sass/theme/library",
    ]
)

styles.scss

@import 'external/npm/node_modules/@angular/material/theming';

//...

The editor doesn't understand the import and flags it as an issue however

/cc @jelbourn yeah I think this is a rules_sass thing. I'll transfer the issue

@alexeagle @jelbourn What's the current recommended way to do this?

I actually don't know myself- @alexeagle should we be putting a BUILD file in our npm release?

Running into this myself. Any new information or workaround?

@achew22 Can you share this vendored solution you made?

I don't think material should publish a BUILD file because you'd want any sass library to work with Bazel.

How would this work with sass outside of Bazel? I think we should make it the same.

We just put a Sass file in the root of our package. With webpack you would just import with the tilde convention

@import '~@angular/material/theming';

Should each application need to define their own sass_library for that file?

seems like maybe you want to port that tilde feature from the webpack sass loader into sass proper? then you'd look through the third-party installed packages to resolve that.

At this point people have written enough webpack-specific code that we have to treat it as standard syntax in order to interop with existing codebases I guess?

@mattem couldn't get this to work.

We're discussing plans for a portable package import scheme in https://github.com/sass/sass/issues/2739. We probably won't end up using the same syntax as Webpack, but it should eventually solve this issue.

I think it's unfair that you should be forced to adopt someone else's syntax, but if you don't use the same syntax as Webpack we need some plan to migrate everyone's code right?

That's true, but the semantics are different enough anyway (e.g. the built-in importer won't support package.json-defined entrypoints) that that's probably a less painful migration than just co-opting the webpack syntax would be.

If the migration is painful then we'll still have webpack sass imports indefinitely and we'll end up having to support them under Bazel too (I suppose maybe in a layer above rules_sass - Angular CLI can't tell all our users to do something painful when we introduce Bazel)

I don't think migrating to pkg: will be particularly painful on the user's end, it'll just take time.

I agree that a migration from ~ to pkg: overall won't be painful, but during that migration period it is sometimes expected to support two build systems (in our case the old, Webpack based Angular CLI and the new, Bazel), so having some support for the ~ would definitely make things easier here.

Is there a recommended approach here? Attempted to use the output of a genrule as the src for sass_binary, but it let to other import issues.

What is the currently recommended/best/correct approach to include external stylesheets?

I agree that a migration from ~ to pkg: overall won't be painful, but during that migration period it is sometimes expected to support two build systems (in our case the old, Webpack based Angular CLI and the new, Bazel), so having some support for the ~ would definitely make things easier here.

Is there a recommended approach here? Attempted to use the output of a genrule as the src for sass_binary, but it let to other import issues.

any progress on supporting the ~ imports? Would be nice to support something like ts_librarys module_name for the scss_library as well.

any progress on this issue?

@Phillip9587 see https://github.com/bazelbuild/rules_sass/pull/122#pullrequestreview-507854016

If I understand the readme of the webpack sass-loader correctly, ~ is deprecated. We added the include_paths option to the solution that @mattem provided and it works with both Bazel and ng build.

BUILD.bazel

sass_library(
    name = "angular_material_theming",
    srcs = [
        "@npm//:node_modules/@angular/material/_theming.scss",
    ]
)

sass_binary(
    name = "global_app_styles",
    src = "styles.scss",
    include_paths = ["external/npm/node_modules"],
    deps = [
        ":app_theme",
        ":angular_material_theming",
        "//some/other/sass/theme/library",
    ]
)

styles.scss

@import '@angular/material/theming';

//...