Feature Request: Use Different Resolver Configuration when Finding Targets of @import Directives

[mvastola]

So I'm a fairly new convert to webpack/yarn -- but an experienced web/rails coder (where I'd been using sprockets). As I am retrofitting my already-existing site with webpack, I'm repeatedly running into one particular annoyance with my codebase though, which leads me to a suggestion that I think would apply to/benefit all users to help include modules in a more robust fashion.

Specifically, the path resolution performed when using an @import directives in a sass stylesheet seems to be a bit less intelligent than what I was used to. In particular, the resolver seems to use the same settings that are used when resolving javascripts and, indeed, any other file.

Firstly, this means that all sorts of non-CSS-ish file extensions are tried in a fixed universal order. This order, by default, appears to have scripts, followed by stylesheets, followed by images. As it's common for package developers to have a .css file and a .js file with the same basename, this requires explicitly specifying the relative path (with extension) within the module of any files one might want to include. The first part of my suggestion would be to only look at a customizable list of extensions when resolving @imports.

Secondly, many npm modules, in their package.json, specify a style key. If this were read, this would allow, for instance @import '~module-name';. Currently the use of this syntax is not possible if the module contains javascript that is at index.js or else is specified by the main key in package.json. I would suggest this be consulted.

[alexander-akait]

@jhnns friendly ping

[artemjackson]

@evilebottnawi

Secondly, many npm modules, in their package.json, specify a style key. If this were read, this would allow, for instance @import '~module-name';. Currently the use of this syntax is not possible if the module contains javascript that is at index.js or else is specified by the main key in package.json. I would suggest this be consulted.

Is there any progress on it?

[alexander-akait]

@artemjackson no, but PR welcome, many works around webpack@4 😞

[alexander-akait]

Close in favor #556, #535 and sass field in package.json