Closed robjtede closed 4 years ago
Hi @robjtede, the problem here is that emoji-toolkit
is specifying devDepedencies as dependencies, thus I suggest to file an issue in their issue tracker.
Changing to logic to prefer sass
instead of node-sass
, will result in a breaking change with the risk of breaking users which depend on node-sass specific behaviour, also in a CLI project, sass
is always available transitively via build-angular package.
In future versions of the CLI will be deprecating node-sass usage.
Thanks for checking it out. Might be one to know about since I can't imagine ngx-markdown is the only package to unknowingly introduce breaking changes in a minor release. Waiting for a reply to the issue on emoji-toolkit.
An observation: it seems very difficult (if not impossible) to provide a strong semver guarantee in the precense of this conditional transitive dependency inclusion. I maintain for now that an explicit developer option at the Angular CLI level would have significant value given that we don't control every depth of dependencies we use.
Hi @robjtede,
An observation: it seems very difficult (if not impossible) to provide a strong semver guarantee in the precense of this conditional transitive dependency inclusion. I maintain for now that an explicit developer option at the Angular CLI level would have significant value given that we don't control every depth of dependencies we use.
Unless, you include 3rd party build tools which set explicitly node-sass as a direct dependency, you shouldn't encounter this problem. And in such case that tool should likely add node-sass/sass dependencies as peerDependencies. IMHO these issues should be fixed upstream rather than providing an option to workaround it. We should consider adding this option in the future if we see this issue is being encountered more often, but this logic has been present in the CLI since version 8 and I don't recall anyone reported it before or a genuine case where adding an option to choose the SASS preprocessor was truly needed.
Adding an option to the Angular CLI increases the public API and increases maintenance especially considering we'd like to deprecate node-sass support altogether.
In addition to that, using a package lock you will guard yourself from accidental direct and transitive dependencies breakages.
Closing as this is not actionable by us. The fix should be done upstream in the emoji-toolkit project.
This issue has been automatically locked due to inactivity. Please file a new issue if you are encountering a similar or related problem.
Read more about our automatic conversation locking policy.
This action has been performed automatically by a bot.
π Bug report
Command (mark with an
x
)Is this a regression?
Probably not.
Description
Angular CLI prefers node-sass if it exists anywhere in the dependency tree.
This has manifested during an update of
ngx-markdown
from 10.0.0 to 10.1.0 in which one of it's dependency has added node-sass as adependency
. The error thrown relates to the SASS implementation not understanding SASS modules.The offending line in Angular CLI goes against a change that was made in sass-loader v9 to prefer dart-sass. Since the current CLI next version of build-angular (
~0.1001.0-next.2
) updates to sass-loader v9, I feel it would be appropriate to either match its behavior or delegate the choice to sass-loader (by not explicitly providing theimplementation
option. If that is considered a breaking change, then perhaps an explicit developer choice is made available under
stylePreprocessorOptions` or something similar.π¬ Minimal Reproduction
Steps and notes in this repo: https://github.com/robjtede/repro-sass-loading
π₯ Exception or Error
π Your Environment
Anything else relevant?
Related issues: