Use the modern Sass API

[nex3]

Parcel currently uses the deprecated legacy API for compiling Sass code. This API is less efficient and less correct than the modern API, and is slated to be removed in an upcoming Dart Sass 2.0.0 release. In order to encourage users to migrate away before that, we'll be adding a deprecation warning to all uses of the legacy API in one of the next few Sass releases.

Also consider adding support for the sass-embedded package, and particularly the Compiler API. When doing multiple small compilations, this API on the embedded host is much faster than the plain-JS sass package.

[devongovett]

I was able to migrate our code to use the new API in #9966, but I'm worried that this might be a breaking change for end users. Projects may include a .sassrc.js file containing arbitrary SASS options, and it looks like those have changed between the legacy and modern APIs. In particular, the APIs for functions, importer, pkgImporter, and a few others have changed. Therefore I'm not sure if this will need to wait until the next major version of Parcel. That would be unfortunate since they are already getting warnings. Is there a way for us to map the old API options to the new ones somehow?

[nex3]

You could probably make a shim for the legacy functions API with some work (or just fork the one the Sass embedded host uses), and pkgImporter should work the same in both cases. The importer API is the big sticking point: the modern importer API specifically has stronger restrictions to enable better guarantees for the Sass stylesheets, so it's not really feasible to make a general-purpose translation layer for that. You may be able to make something work that supports a particularly well-behaved subset of user-defined importers, though.

Since the legacy API has been deprecated for years now, we're planning to drop support in Dart Sass 2.0.0 which will probably be released some time in Q1 2025. At that point, we unfortunately won't have the bandwidth to keep making CSS compatibility changes to the 1.x line.

[valentinoConti]

I don't know what changed but from one day to another I started getting a hell of:

DEPRECATION WARNING: Sass @import rules are deprecated and will be removed in Dart Sass 3.0.0.

More info and automated migrator: https://sass-lang.com/d/import

I refactored all my code to use the new @use and @forward syntax of sass instead of @import, and then those warnings were gone but I started having a hell of other deprecation warnings, related to JS API and merged deps and etc.

I tried everything to fix it and wasn't able;

I think that this issue is what is missing, parcel needs support for the new stuff, I guess sooner or later will be there, for now, and I comment this for others going trough the same, the solution was simple:

keep everything as it was, dont refactor anything and just add:

  "resolutions": {
    "sass": "1.38.0"
  },

in the package.json

no more warnings or anything, just kept my sass the old-school way and everything keeps working fine. for some reason even if parcel has 1.38.0 as dependecy, the installed version was 1.8x.

[nex3]

@valentinoConti I strongly recommend passing the silenceDeprecations flag rather than using an old version of Sass. Those old versions aren't maintained and become more and more incompatible with modern CSS over time.

[valentinoConti]

@valentinoConti I strongly recommend passing the silenceDeprecations flag rather than using an old version of Sass. Those old versions aren't maintained and become more and more incompatible with modern CSS over time.

Sounds good, will do, thanks! hope that parcel updates support for newest stuff soon 🙌🏼

[devongovett]

I'm still not exactly sure how we can do that without waiting for a major version of Parcel. Maybe there's a way to detect if a config is compatible with the new or old version of sass and load the corresponding version?

[nex3]

Yeah, that should work. There's very little overlap between the legacy options and the modern options, so you should mostly be able to just look for any keys that are only in the latter and use the modern options otherwise.

There are only two keys that are valid in both options without having identical semantics:

• sourceMap (modern vs legacy): in this case it works the same if you pass a boolean, so you can just opt into legacy mode if the value is a string.

• functions (modern vs legacy): This is trickier, because both options take a map from function signatures to implementations. If any function takes more than one argument, it's definitely using the legacy API, but one-argument functions are unavoidably ambiguous. You may need to opt this in to legacy mode by default for backwards-compatibility.

That said, even with the functions exception this would fix the warning for the vast majority of users who aren't passing any special configuration or are just passing deprecation controls.

[tylerlong]

Any plan to release a new version of parcel? Or do we need to wait for 3.0? I see that the last time we released a new version is 8 months ago.

[devongovett]

Yes, working on that, aiming for within the next week or so. Sorry for the delay.