Closed amccloud closed 8 years ago
@bholloway sorry! I found the actual issue. My sass partials are not in the same directory as the entry sass file. Since the file search is relative to the usage of url()
and not the entry file my assets are not being found.
@import '../common/example'
.example {
background-image: url('images/logo.png'); // Searches in /common
}
Hey @amccloud. Sorry about the delay in responding, something is wrong with my email notifications and I only just saw your issue.
If this resolved for you, will I close the issue?
My original issue is resolved but there is some sort of limitation with sass partials that are not in the same directory as the entry point.
On Sunday, February 21, 2016, Ben Holloway notifications@github.com wrote:
Hey @amccloud https://github.com/amccloud. Sorry about the delay in responding, something is wrong with my email notifications and I only just saw your issue.
If this resolved for you, will I close the issue?
— Reply to this email directly or view it on GitHub https://github.com/bholloway/resolve-url-loader/issues/16#issuecomment-186986371 .
@amccloud let me back up to see if I have your use-case correctly.
The aim of this loader is to ensure url()
statements resolve relative to the file containing the url()
statement. Therefore, you would need to put the logo.png
in the /common
directory.
However this is not the case; you have a /images
directory elsewhere in your project that contains all your images. Therefore I suspect that if your remove resolve-url-loader
you will get your desired behaviour by default.
But if this case is the exception to the rule you will want to keep resolve-url-loader
for the rest of your .scss
files. So you could try specifying the loader sequence explicitly where you are require()
ing the main.scss
file.
Regardless, there are some limitations with mixins and functions. There are limits to how SASS constructs the source-map. You may need to play around a bit to see how best to organise your code.
Is this any help?
The aim of this loader is to ensure url() statements resolve relative to the file containing the url() statement. Therefore, you would need to put the logo.png in the /common directory.
This confuses me, because this is actually the current behaviour, but without resolve-url-loader. This is my configuration:
{
test: /\.sass$/,
loader: 'style!css!sass?indentedSyntax',
include: [helpers.root('/src')]
}
Now, I have a kind of global asset folder and I reference this folder using a sass variable with an absolute path (relative to my src project). This variable is used in every sass file to resolve the images without having to specify a (complex) relative path. This setup works well in development mode, but when building the project with webpack, all absolute url are ignored (and it expects they are resolved from my src folder, which obviously fails...). I had hope that resolve-url-loader would help to copy my absolute assets and/or change automatically the path from absolute to relative so that css-loader may work as expected, but this does not seem to be the aim of this module, right?
edit: please ignore my comment, my issue is solved (by using root
in css-loader).
Sorry @Krisa I made a mistake with my statement (the one that you have quoted).
resolve-url-loader
the images need to be relative to _example.scss
. You would co-locate your assets with the file that contains the url()
statement.resolve-url-loader
the images are relative to your sass entry point, meaning main.scss
.Per your comment, I would expect css-loader
to find assets and add them to the bundle. If this is not happening then that you should solve that. Under normal circumstances you shouldn't need root
.
Make sure that you have a loader for your actual assets. This can just be the file-loader
. You should see them copied to your output directory and their new path rewritten in the css url()
statement. You should also see them listed in the console output at the end of your build.
I'm going to close this issue per @amccloud's statement.
However please continue to comment on this thread until you are happy with your outcome.
This subject may get clearer if we have better source-map resolution than reworkcss
can provide.
Not sure if this is by design but it appears relative urls are being ignored.
See https://github.com/bholloway/resolve-url-loader/blob/master/index.js#L206-L208