dart-sass?

[jethrolarson]

Is there any intent to swap to using https://github.com/sass/dart-sass when it goes gold?

Supposedly it's way faster, and speed hasn't been one of sass's strong points.

[alexander-akait]

@jethrolarson 'dart-sass' is cool project, but there are a lot of bugs with sass original compatibility 😭

[michael-ciniawsky]

Agreeing with @evilebottnawi here, dart-sass is still under 'heavy' development and doesn't cover the whole SASS spec yet

[lukepolo]

Just went into beta , may be with looking into now

[alexander-akait]

@lukepolo seems more related to node-sass, we should have dart-sass port on nodejs. Now we don't have this port and it is impossible.

[graingert]

@evilebottnawi you can do npm install sass https://github.com/sass/dart-sass#from-npm

[alexander-akait]

@graingert can you explain why dart-sass is better (or not) than node-sass? Faster, better compatibility with orginal sass implementation or other feature. But main problem is dart-sass don't support custom importer, without this feature, it is impossibly to implement support dart-sass in sass-loader.

[graingert]

@evilebottnawi saves waiting for the compile step on npm install

Also it's the future of sass: http://sass.logdown.com/posts/1022316-announcing-dart-sass

[nex3]

@evilebottnawi Importer support is a high-priority feature for Dart Sass; we consider it blocking a 1.0.0 stable release.

[FossPrime]

For those googling around on how to use dart-sass instead of libsass/SassC in Vue, the answer is you can't. Until it has webpack/vue-loader/sass-loader support. Which can't happen without importer support, even if you are willing to simplify your sass to work with dart-sass.

You can follow progress here sass/dart-sass#12

[nex3]

I just put out sass/dart-sass#186 which adds support for synchronous importers. I hope to land it tomorrow. Asynchronous importers will take more work, but this is an important step.

[graingert]

Looks like @nex3 has merged async import support, can you reopen this ticket @michael-ciniawsky?

[nex3]

I'm planning to release a beta release with async importer support later this week. If possible, this should pass the fibers package to render() if it's using the asynchronous render() function; otherwise, it will run substantially slower than renderSync(). See the README for details.

[reinerBa]

For me it would be greate if the sass-loader would support the usage sass compiler because node-sass forces me to install node-gyp which is sometimes a big problem :( as Golo describes here in a node-sass issue

[nex3]

Dart Sass is in Release Candidate phase now, with a full release probably coming next week. I'm happy to help write up a pull request to add support, but there are a couple of design questions that should probably be addressed by the maintainers first:

1. How do users specify which implementation to use? One option would be to allow them to write

   {
     loader: "sass-loader",
     options: {sass: require("dart-sass")}
   }

   or even

   {
     loader: "sass-loader",
     options: {sass: "dart-sass"}
   }

   Would it continue to default to loading Node Sass? Or would adding this option be a breaking change?

2. What do we do about imports that load CSS files as SCSS? This is a LibSass-only (mis)feature that's on its way to being deprecated (LibSass should not import CSS files, let alone as SCSS sass/libsass#2611), and is not supported by Dart Sass. However, this package's tests exercise that feature. Should we delete the tests that exercise the feature (since it's a Sass implementation issue more than a loader issue), and tell downstream users to add a custom importer if they want to continue using it once LibSass drops support?

[alexander-akait]

Should be done after #533

[ghost]

@jethrolarson @evilebottnawi
Some posts about ruby-sass. Now it's actual
http://sass.logdown.com/posts/7081811

[nex3]

Now that #533 has landed, what are the next steps here?

[jhnns]

Wow ruby-sass was deprecated? Didn't see that coming 😁

Are you planing with dart-sass to expose the same API as node-sass? What notable differences are there between dart-sass and node-sass?

Regarding your suggestions:

From a conceptual perspective, I prefer the former one with require() because it pushes the dependency explicitly to the user. But since we already need to apply some fixes for node-sass (e.g. the async job queue), I think it's better to have the latter in place. This way, we can apply fixes and adjustments as necessary.

What do we do about imports that load CSS files as SCSS?

We should remove that feature with a breaking change since it's deprecated anyway. Until then, I can add the same deprecation warning as in sass/libsass#2613.

---

If dart-sass is mature enough and reliable, I'm open to switch to dart-sass as the new default. I suspect the node-sass' thread pool issue (sass/node-sass#857) to be responsible for the performance problems at sass-loader #296 since we're using the custom importer feature.

[xzyfer]

Sure if you're running an install every time you compile your Sass code in dev.

[graingert]

It ends up happening a lot, eg when building docker images using Dockerfile

[alexander-akait]

@graingert you can prepare docker image before run some stuff

[graingert]

@evilebottnawi I know that, I used to maintain shipwright a tool for doing just that, but sometimes it's fiddly

[nex3]

Could you actually use the real dart version as a backend instead of a to-javascript-transpiled one?

Integrating the Dart VM version into a package like this which supports the Node Sass API would be fairly difficult. When you're running a subprocess, it's much harder to define importers or custom functions, because they have such a fine-grained mode of communication. sass/dart-sass#248 discusses the possibility of defining a protocol that could be used over stdin/stdout to make this work, but at the moment we don't have anyone signed up to implement the JS side of that protocol.

If you're willing to abandon importer/custom function support, it would be a lot easier to wrap the Dart executable. This is essentially how the grunt-contrib-sass package works with Ruby Sass. But that's not a sacrifice everyone would be willing to make.

[FossPrime]

But that's not a sacrifice everyone would be willing to make.

We are already making a lot of painful sacrifices to use sass with node-sass. There are a LOT of benefits to switching... sharing node_modules with docker, faster compilation, never break my installation after a node/system update, just to name a few... node-sass is a pita, dart-sass can't possibly be worse.

To be fair, I get it won't be easy to make the switch, it'll inevitably have to be a breaking switch, perhaps an installation option to make it easier, similar to how less support is set up?

Update: whoops, thought this was vue-cli

[xzyfer]

Fwiw node-sass installation issues will be a thing of the past before too long

…

On Sat., 7 Jul. 2018, 11:38 am Ray Foss, ***@***.***> wrote: But that's not a sacrifice everyone would be willing to make. We are already making a lot of painful sacrifices to use sass with node-sass. Sharing node_modeles with docker, faster compilation, never break my installation after a node/system update, just to name a few... node-sass is a pita, dart-sass can't possibly be worse. To be fair, I get it won't be easy to make the switch, it'll inevitably have to be a breaking switch, perhaps an installation option to make it easier, similar to how less support is set up? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#435 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAjZWFJTw0FMOkEskeT0JDifU2d-CsW_ks5uEBEDgaJpZM4M60Gd> .

[matoilic]

@xzyfer Can you elaborate this further? Are there plans to optimize node-sass' compilation?

[graingert]

N-API and or wasm I believe

…

On Sat, 7 Jul 2018, 10:25 Mato Ilic, ***@***.***> wrote: @xzyfer <https://github.com/xzyfer> Can you elaborate this further? Are there plans to optimize node-sass' compilation? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#435 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAZQTIX4aQcLs4xbCt5JaNZ04fJoyPknks5uEH57gaJpZM4M60Gd> .

[just-boris]

I have switched to the modified version of this loader (from #573) and dart-sass for a fairly big project (10k lines of SCSS) and did not notice any significant slowdown. It could be slower, but with watch mode and incremental builds, it doesn't actually matter.

On other hand, it simplifies infrastructure a lot, when you have to deal only with pure Javascript dependencies.

[samayo]

What is the status of this issue? Can we use now dart-sass in webpack? I can't see any documentation to for the webpack config

[Simek]

@samayo Official NPM package sass has been switched to Dart implementation a while ago (https://www.npmjs.com/package/sass) so you do not need to use/change to dart-sass (it's a mirror).

[samayo]

@Simek Thanks, I do have sass and sass-loader

"devDependencies": {
  "sass": "^1.23.0",
  "sass-loader": "^8.0.0"

and I have the loaders setup correctly

{
 test: /\.s[ac]ss$/i,
  use: [
   'style-loader',
   'css-loader',
   {
   loader: 'sass-loader',
    options: {
     implementation: require('sass'),
    },
   },
  ],
}

The config is as suggested in https://github.com/webpack-contrib/sass-loader#implementation

But I can't seem to use the sass module features as mentioned in https://sass-lang.com/documentation/at-rules/use

If npm/sass is just fetching dart-sass, these options should be available, i think.

[Simek]

@samayo Check out this issue: #766. It seem that it's quite a new feature and it's not fully supported yet.

Tests has been added just few days ago:
185ba80

[samayo]

@Simek Thanks. I still can't verify if this feature is added or not from reading the commit. It seems like the readme is updated, tests written but feature isn't there yet? I will ask on dart-sass if they can make something of it, but thanks ... at least now i'm half certain i'm not going mad :)

[alexander-akait]

We officially support dart-sass with @use what is problem? Check you use sass and dart-sass and use latest version of loader

[stratboy]

Currenly experiencing the same problem: latest sass-loader doesn't fully recognize current scss syntax. Using:

    "sass": "^1.49.7",
    "sass-loader": "^12.6.0",
     "webpack": "^5.69.0",