Workspace library scss import

Start with the build and generate paths for a workspace library, using the generated dist/my-company/my-lib/assets/_theme.scss, its package.json exports entry, and projects/app/src/styles.scss as reproduction points. Run the app's @use import and inspect the generated tsconfig.json settings; done means the exported SCSS resolves without manual path or npm-link workarounds.

🚀 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.