Support for resolving imports while using stylePreprocessorOptions in angular.json

[tarangkhandelwal]

If using with Angular framework, imports could be via stylePreprocessorOptions where there won't be a relative/absolute path but just files names that are in directories specified under stylePreprocessorOptions.includePaths.

Currently the lint rule break if such an import is present:

Error: ENOENT: no such file or directory, open 'importedfile.scss'

[juanca]

I don't have much context on Angular or stylePreprocessorOptions. However, these stylelint rules do allow customization of "include paths."

The rules expose a secondaryOptionObject argument which I believe is the second parameter when configuring the rule. The parameter is an object with shape of:

{ resolve: { alias: {}, modules: [] } }

For configuring include paths, populate the modules array with the paths!

I haven't documented this since I sort of just copied the spirit of Webpack on this one. If it works well for you, I can document alias and modules for posterity's sake.

[tarangkhandelwal]

Thanks @juanca for the suggestion. It does solve the issues partially for me.
There are variants that we use in angular/typescript app. For e.g.

1. src/app/module/mystyle.scss could be refered as: "~app/module/mystyle.scss"
2. Import without .scss extension.
   @import "./mystyle" is also valid and working.
3. I am defining my variables in styles.scss while is global in angular. This is not considered while deciding if a variable is defined in application context or not.

Note: I am using rule "css-modules/css-variables".

[juanca]

The webpack resolution algorithm might be able to solve all of these:

1. src/app/module/mystyle.scss could be refered as: "~app/module/mystyle.scss"

{ resolve: { alias: { '~': 'path/to/app/root' }, modules: [] } }

2. Import without .scss extension.
   @import "./mystyle" is also valid and working.

Looks like I'm missing { resolve: { extensions: [] } from https://webpack.js.org/concepts/module-resolution/

I can look into supporting this EOW. I'm also open to a PR -- we can either implement extensions or we might be able to use their resolver: https://github.com/webpack/enhanced-resolve

3. I am defining my variables in styles.scss while is global in angular. This is not considered while deciding if a variable is defined in application context or not.

Can you provide some example code? It'll help me compare it against my conceptual model of css-variables.

[tarangkhandelwal]

For the 1st problem, there could be multiple paths using '~' . Not sure if we would be able to specify them.
There could be different possible import patterns: "~app/module/mystyle.scss", "~app/module1/differentStyle.scss", "~app/parent-module/child-module/childStyle.scss".

For the 3rd:
We could define variables in style.scss.
Style.scss is defined to be injected globally (Angular cli feature).
https://angular.io/guide/workspace-config#style-script-config
e.g.
:root {
--primary-background-color: #FFFFFF
--secondary-background-color: #FFFFFF
--primary-border-color: #CCCCCC
--error-border-color: #FF0000
--text-color: #000000
--sub-text-color: #737373
}

[juanca]

I have a couple of the solutions in a PR: #28

The only problem left to solve is adding a way to specify globally available CSS variables. More to come!

[juanca]

I should have #28 already released under 1.2.0. I am still working through the globally available files in #29 -- it is pre-released under 1.2.0-globals.

You will want to configure your global files as an array files: globals: [absolute_path_to_file, absolute_path_to_file2]

Do you mind seeing if these fix your use-cases?