Resolve Deprecation Warnings by Migrating Dart Sass

[msmx-mnakagawa]

#240 → #239
resolves: #232

What I did

• apply a patch from #232 (comment) to resolve warnings like Deprecation The legacy JS API is deprecated…
• migrate a compile process of Dart Sass
• enhance certain tests to ensure the change
• update the interface around importer (not finalized)
• update the document around importer

Discussion points

Now this PR is still draft due to the following points:

Design of the importer Interface

The latest Dart Sass and Node Sass interfaces significantly differ.
Therefore, this PR currently stops treating both importer interfaces as one.

The prospective interface employs a union type.

Details of the interface design

Before

typed-scss-modules/lib/sass/importer.ts

Lines 1 to 7 in e80c68e

	import { SyncImporter } from "node-sass";
	import { LegacySyncImporter } from "sass";
	// Hacky way to merge both dart-sass and node-sass importer definitions.
	type Importer = LegacySyncImporter & SyncImporter;
	export { Importer };

Now

type SASSOptions = (
  | {
      implementation?: "node-sass";
      nodeSassImporter?: …; // ↓ the different naming from `Dart Sass`'s one
    }
  | {
      implementation: "sass";
      sassImporter?: …; // ↑ the different naming from `Node Sass`'s one
    }
) & {
  … // common definitions
};

I'd like to confirm whether there is any better solution.

Support for Deprecated Node Sass

Node Sass is now deprecated as announced below.
https://sass-lang.com/blog/node-sass-is-end-of-life/

I am open to discussions on whether and when to discontinue support.

Available options

I see two possibilities (suggestions are welcomed):

1. Continue supporting Node Sass for a while (and remove it after that), using the union interface

• Pros:
  • Less impact on users, gradual choice
• Cons:
  • More complex interface for users unless a better design emerges
  • Difficult maintenance for developers

2. Remove Node Sass support, and using a non-union interface

• Pros:
  • Simple interface for users
  • Easy to maintain for developers
• Cons:
  • Immediate and significant impact on users

I invite discussions on the best approach.
※ As either option involves breaking backward compatibility, we will update the major version regardless.

[doberkofler]

I would definitively prefer option 2 and remove Node Sass support

[msmx-mnakagawa]

Thank you for your prompt confirmation, @doberkofler.
Considering Node Sass is already deprecated, discontinuing its support may raise few issues.

Regarding ceasing Node Sass support:

• For simpler review and maintenance, creating a separate PR solely for Node Sass removal, distinct from this one, would be advantageous.
• If agreed upon, I'll create that PR.

In the meantime, I suggest we wait for further opinions from others.

[krzysztof-cislo]

I am also for dropping the support for Node Sass fully. It's already a deprecated package for longer time.

Regarding breaking changes I see no problem with releasing new major version which will clearly inform about it.

[msmx-mnakagawa]

Thanks for your perspective, @krzysztof-cislo.
Agreed, the discontinuation of Node Sass support, given its longstanding deprecation, will likely have minimal user impact.

Given multiple responses advocating for dropping Node Sass, I'll try to create a separate cleanup PR, if it's fine.
Please bear with me for a while.

[msmx-mnakagawa]

(cc: @doberkofler @krzysztof-cislo)

As previously mentioned, I've created a PR #240 for dropping Node Sass support.
Before reviewing this migration PR, would someone be able to take a look at the cleanup PR #240?