Workspace library scss import

Comece pelos caminhos de build e generate de uma biblioteca de workspace, usando dist/my-company/my-lib/assets/_theme.scss, a entrada de exports de package.json e projects/app/src/styles.scss como pontos de reprodução. Execute a importação @use do app e inspecione as configurações do tsconfig.json gerado; considera-se concluído quando o SCSS exportado é resolvido sem soluções alternativas manuais de caminho ou npm-link.

🚀 Feature request

Command (mark with an x)

• new
• build
• serve
• test
• e2e
• generate
• add
• update
• lint
• extract-i18n
• run
• config
• help
• version
• doc

Description

With a workspace architecture, the exported stylesheets cannot be imported using package name. Given a library (lib) and a project (app) in an angular workspace. The library properly copies an scss file to the dist folder (which is the default output folder) and adds it to the exports section of the package.json. However, the consuming app cannot @import or @use the exported scss file.

Given the following files:

• dist/my-company/my-lib/assets/_theme.scss
• projects/app/src/styles.scss

And the following export in the package.json of the library:

"exports": {
  "./theme": {
    "sass": "./assets/_theme.scss"
  }
},

And the default settings that the Angular CLI generates (with ng new library and so on...),

Describe the solution you'd like

With the settings mentioned above, importing an exported scss file should work out of the box (currently it does not compile with the error SassError: Can't find stylesheet to import.).

// styles.scss
@use "@my-company/my-lib/theme" as myTheme;

Describe alternatives you've considered

1. Changing the default dist output of the library to the node_modules and the automatically removed @ symbol is added to the path (in short dist/my-company/my-lib -> node_modules/@my-company/my-lib) resolves the scss import problem. The tsconfig.json must be adjusted as well. If this is the desired solution, then it should be the default generated with the CLI.
2. Create an NPM Link to the dist directory (which has its own pros and cons). If this is the desired solution, then the tsconfig.json does not need to define additional paths and this should be an operation that the generation (through the CLI) does automatically. Or at least extend the documentation.