TL; DR

If you find that sas-loader does not recognize /deep/ in a new project, please refer to the following suggestions:

  • use::v-deepSyntactic substitution (supported by different sASS implementations)
  • Use Dart-Sass instead::v-deepgrammar
  • It is best tosass-loaderThe specifiedimplementationparameter

If a historical project has been using node-sass + /deep/ for development, but sas-loader suddenly does not recognize /deep/ syntax, check whether sas-loader actually loads SASS (Dart-sass).

Methods:

Resolve (‘sass’). If the module resolves successfully and returns the path of the sass package, sas-loader has incorrectly loaded sass instead of Node-sass.

Problem description

In an old project maintained by the author, the technology stack is Vue, which uses Sass-Loader + Node-sass to parse SCSS syntax.

The problem occurred on a sunny afternoon when I was isolated at home. After starting the yarn Start project, I was about to report the business requirements, but I found that the page could not be opened and the error content was as follows:

SassError: expected selector. /deep/ ...

When I first saw the error, I immediately checked whether the version of sass-loader node-sass installed in my node_modules project was changed, and I found that the version of sass-loader installed was the version specified in yarn.lock.

However, I removed node_modules and re-installed project dependencies, and the problem persisted.

Confused, I even asked my colleague to air drop a whole node_modules to me to eliminate the influence of the environment. As a result, the same dependency and the same code can run normally on his computer, but it reported an error on mine.

Sass-loader was loaded incorrectly because sass was installed in node_modules.

I cleaned out the global node_modules folder and found the problem was still there.

To view the document

Very confused, I thought that I had eliminated the influence of the code and the global environment, and began to suspect the problem of the Sas-Loader package itself. I opened github.com/webpack-con… I started to turn over the issue, but I didn’t get anything. But in README:

So I try to specify the implementation of the SCSS syntax to sass-loader as Node-sass:

module.exports = {
  module: {
    rules: [
      {
        test: /.s[ac]ss$/i,
        use: [
          "style-loader",
          "css-loader",
          {
            loader: "sass-loader",
            options: {
              implementation: require("node-sass"),
            },
          },
        ],
      },
    ],
  },
};
Copy the code

Restarting the project worked!

Implementation is node-sass, but sass-loader has always recognized node-sass.

Continue to see what the document says:

So I checked the project’s package.json:

If pass-loader is used to check package.json, it should be able to get it properly. Curious, I clone the Sass-Loader, ready to find out!

Soga (So it is)

Github.com/webpack-con…

The getSassImplementation method is called in the index.js/loader method of the sass-loader entry

Github.com/webpack-con…

GetSassImplementation in judging if the loader is not specified in the options implementation will call getDefaultSassImplementation

Github.com/webpack-con…

Sass (Dart-Sass), Node-Sass, and Sass-Embedded (SASS is maintained by the same team with the version of the same API. Faster, but requires dart’s runtime environment).

The sass-loader does not use Node-sass because it can be loaded into sass in my project.

So I immediately went to my project root directory, started Node, ran require(‘sass’), and sure enough, sass was successfully loaded!

So the culprit?

And that’s when I was completely enlightened. At the same time, I was working on a new project. One day, in order to simulate the Jenkins build environment of the company, I pulled the company’s build image to run in the local Docker container.

Node_modules should be reinstalled when using docker cp to copy local projects into docker containers. But in order to avoid again in local installation, I put the node_modules temporarily moved to the higher level directory (i.e. above/Users/yongjia. Lin/projects), plans to move back after docker cp.

But IT didn’t take long for me to forget about it, and the old project was innocently affected…

conclusion

However, the old project is not so innocent. It is better to specify the implementation parameter in sass-Loader to avoid being affected by the external Schrodinger sass. Don’t use Node-sass for new projects