bholloway / resolve-url-loader

Webpack loader that resolves relative paths in url() statements based on the original source file
563 stars 71 forks source link

Migrating to new `join` function #204

Closed danielgindi closed 3 years ago

danielgindi commented 3 years ago

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!

bholloway commented 3 years ago

@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.

danielgindi commented 3 years ago

@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 :-)

bholloway commented 3 years ago

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.

danielgindi commented 3 years ago

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!