Allow custom mainFields and extensions for getResolve

[deAtog]

• Operating System: All
• Node Version: n/a
• NPM Version: n/a
• webpack Version: 4.27.0+
• sass-loader Version: trunk

Feature Proposal

The sass-loader plugin should allow the user to customize the mainFields and extensions used to resolve imports. The current defaults shown below may be insufficient for all use cases:

mainFields: ['sass', 'main'],
extensions: ['.scss', '.sass', '.css'],

E.g. 'style' is not included in mainFields by default.

Feature Use Case

CSS imports may be specified by other properties in the package.json file and may have additional extensions. The plugin should allow the user to specify these settings in order to support other package.json property names and additional file extensions.

E.g. @fortawesome/fontawesome-free has a package.json file which lacks a 'sass' property, but contains a 'style' property. Due to the current non-modifiable defaults in this plugin, users must continue to use the full path in the @import statement.

[alexander-akait]

Already supported https://webpack.js.org/configuration/resolve/

{
  resolve: { 
    mainFields: ['sass', 'style', 'main'],
  },
  loader: 'sass-loader'
}

Also this feature is not publish right now.

Maybe we should support style field by default. But it is good practice have in style field css and scss/sass in sass field, feel free to create issue in font-wasesome repo

[deAtog]

Published or not, does not matter. This does not seem to work with Webpack 4.28.0.

The error states the following:

configuration.module.rules[4].use[3] has unknown property 'resolve'. These properties are valid:
object { ident?, loader?, options?, query? }

On lines 40-46 of loader.js, the sass loader has the following:

// Supported since v4.27.0
if (this.getResolve) {
    resolve = this.getResolve({
        mainFields: ['sass', 'main'],
        extensions: ['.scss', '.sass', '.css'],
    });
}

As initially stated, the sass-loader does not provide an option to override the options passed to getResolve.

The getResolve function of Webpack's NormalModule.js is defined as:

getResolve(options) {
    const child = options ? resolver.withOptions(options) : resolver;
    return (context, request, callback) => {
        if (callback) {
            child.resolve({}, context, request, {}, callback);
        } else {
            return new Promise((resolve, reject) => {
                child.resolve({}, context, request, {}, (err, result) => {
                    if (err) reject(err);
                    else resolve(result);
                });
            });
        }
    };
},

The getResolve function either creates a resolver with the options provided OR uses the global Webpack resolver. There is nothing here to indicate that any other options are used. Additionally, it would seem that the options passed to getResolve in loader.js would override any user provided options, hence the feature request.

[alexander-akait]

@deAtog you have invalid configuration for loader, it works since webpack@3 (or maybe with webpack@2 even)

As initially stated, the sass-loader does not provide an option to override the options passed to getResolve.

And should not it is internal webpack resolve mechanism you should use loader.resolve https://github.com/webpack/webpack/blob/master/schemas/WebpackOptions.json#L1508 or https://webpack.js.org/configuration/resolve/

The getResolve function either creates a resolver with the options provided OR uses the global Webpack resolver. There is nothing here to indicate that any other options are used. Additionally, it would seem that the options passed to getResolve in loader.js would override any user provided options, hence the feature request.

Feel free to create issue in webpack

[deAtog]

@evilebottnawi the resolve option there is for an entire ruleset, and loaders specified in the use list do not have this option, hence the error. Regardless, the options passed to getResolve in loader.js override that option.

resolver.withOptions is defined as:

resolver.withOptions = options => {
    const cacheEntry = childCache.get(options);
    if (cacheEntry !== undefined) return cacheEntry;
    const mergedOptions = Object.assign({}, originalResolveOptions, options);
    const resolver = this.get(type, mergedOptions);
    childCache.set(options, resolver);
    return resolver;
};

The mergedOptions created with Object.assign does not merge the contents of the arrays for the mainFields and extensions properties of the options provided, it OVERWRITES them. Thus, if sass-loader is going to call getResolve with options specified, it MUST provide a way for users to override them. I don't know if there's a way for the sass-loader to determine if the 'resolve' option has been specified for a given rule but maybe it should only override them when they are not present?

Adding the 'resolve' option to the main rule no longer works in the trunk version due to this change.

[alexander-akait]

@deAtog resolver.withOptions should merge existing resolver options with passing from loader, looks it is bug in webpack, so create issue in webpack.

[alexander-akait]

@deAtog and work on next version of sass-loader is not ended and not fully tested, so I do not understand your concern and waste of time for work which is still in progress

[deAtog]

@evilebottnawi I was not initially aware of the resolve option for rules in the Webpack.config as it is not well documented. However, I noticed that the trunk version of the sass-loader contained a commit with the message of: "fix: prefer 'scss', 'sass', and 'css' extensions in resolving (#645)" which mostly addressed the frustration I had with using import inside of a scss file. As I have just recently discovered, this breaks configurations where users have provided a resolve option for the rule.

I'm not quite certain if this is necessarily a bug in Webpack as I wouldn't expect the resolve option provided in the module rule to be merged with defaults specified in the loader. One would expect module.rules.resolve to override any defaults a loader has specified. Additionally, if permitted in a future release of Webpack, one would expect any resolve option specified for a loader in the module.rules.use list to override any defaults provided by the loader and any resolve options specified for the rule.

To recap:
module.rules.resolve works with sass-loader 7.1.0
module.rules.resolve does not work with the trunk version of sass-loader

[alexander-akait]

@deAtog

To recap:
module.rules.resolve works with sass-loader 7.1.0
module.rules.resolve does not work with the trunk version of sass-loader

resolver.withOptions should respect webpack.resolve and module.rules.resolve, looks it is bug in webpack, now we rewrite all tests on jest and adding new tests, it was caught on tests and will be fixed

[alexander-akait]

Let's reopen issue to ensure we add tests on this cases

[alexander-akait]

Fixed in next webpack/webpack#9126