bholloway/resolve-url-loader

Migrating to new `join` function

danielgindi opened this issue · 4 comments

Hi!

I had a join function which worked perfectly:

    join: (filename, options) => {
        return (uri, baseOrIteratorOrAbsent) => {
            return Path.join(Path.dirname(filename), '../', uri);
        }
    }

The purpose is to look for all resources one folder up, As the scss in a subfolder relative to the css root folder.

Now with v4 I tried many different combinations:

  createJoinFunction(
      'myJoinFn',
      createJoinImplementation(function* (item, ...rest) {
          for (let [base, uri] of defaultJoinGenerator(item, ...rest)) {
              yield [base.substr(0, base.lastIndexOf('/')), uri];
          }
      }),
  )

or yield [decodeURIComponent(base.substr(0, base.lastIndexOf('/'))), uri]; etc.

I resorted to substr and decodeURIComponent as on windows C:\ causes it to emit errors about base not being absolute, and so does '%20' in the path (space in on of the folders).
So I finally got through to it actually accepting the paths I throw at it, and it still gives the wrong results. For some paths it tries to resolve with extra ../../../../../ prefixed to the path.

The situation is all scss files are imported by the main scss file - and they all mention resource urls as relative to the root scss file.
But it seems like the new version is somehow resolving the paths relative to the sub-scss files.

Is there any way to have a backwards compatible join function? As createJoinImplementation really does not do the job.

Thank you!

@danielgindi I’ve read this a couple of times. I don’t see any obvious reasons why it would do this.

If you can please provide a small OSS project that is a minimum breaking example of the problem then I can boot a windows VM and take a look.

That said also please consider that if everything is relative to your root SCSS file then you are probably not ticking the necessary boxes in the readme. In which case you might not need this loader.

@bholloway that will take some time. I'll try to get to this later this week.

Can you answer this: What is the replacement for the filename argument previously passed to the join function?
Because that argument is what contained the correct path for the file, from which I only needed to traverse up one level and append the uri.
If I know where do I get that argument from, then I can try an actual equivalent for the old join function and report with the results :-)

Ah now I see you are using the filename.

The file being processed is the loader.resourcePath, see the collapsed arguments reference.

In V4 you get full access to the webpack loader context, for better or worse.

Well, loader.resourcePath solved it!
I think this should probably be documented in the docs, with a clear example of a migration path from v3 to v4. Will save a lot of trouble for some people :-)
Thank you!