feat(index): add a new parameter to publicPath (options.publicPath)

[claudiocantara]

This change makes the publicPath function to return the original path of the resource making possible to build custom or relatives paths.

[jsf-clabot]

Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
1 out of 2 committers have signed the CLA.

✅ claudiocantara
❌ Claudiomar

---

Claudiomar seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.

[claudiocantara]

This is a exemple how to use this funcionality

//... other webpack config 
loader: "file-loader",
options: {
name: "[name].[ext]?[hash]",
 outputPath: "img/",
 publicPath: ( file , resource ) => {
  // resource can be  'src/templates/pages/firstPath/secondPath/index.pug';

   const basePath = resource.split('src/').pop();  //get the base of resource
   const compareBaseName = path.basename(basePath, '.pug'); 
   const pagesFullPath = basePath.match(/(?:(?=pages\/)(?:.*)[(?=\/)])/).shift();

   const isRoot = pagesFullPath.match(/[^(?:pages)].+$/);

   if (basePath == 'css/style.scss'){
      return `../${file}`;
   }else {
      if( compareBaseName == "index" ) {
         return !isRoot ? `assets/${file}` : `${path.relative(pagesFullPath,'pages/')}/assets/${file}`;

      }   else {
          return `${path.relative(`${pagesFullPath}/anotherPath`,'pages/')}/assets/${file}`;
              }
      }
  },
 // .. at the end it returns '../../assets/img/my-img.png';

PS: using the file-loader parameter 'useRelativePath' didn't resolve my relative path.

[alexander-akait]

Please add tests

[michael-ciniawsky]

Can you please elaborate more on this change and why it is needed?

[claudiocantara]

Test added

[claudiocantara]

Sometimes it is necessary to create relative paths for the generated files, but 'useRelativePath' options, is based on the structure where the file is being processed, but should be based on the new structure generated by the bundle. If my generating structure has paths other than the generated one, there will be path conflicts. With this new change the developer can create the own relative path for the generated files.

Example :

project
└─src
│ └─folder
│   └─folder2
│      └─folder3
│        │ fileWhoCallImage.ext
│ └─img
│   │ imageReference.png
└─dist
│ └─assets
│   └─img
│     │ imageReference.png
│ └─folder
│   │ fileWhoCallImage.ext 

Using 'useRelativePath' in this example. the relative path generated will be '../../../', but i need '../',
with the second parameter at publicPath i can find out my relative path with a custom
algorithm.

[michael-ciniawsky]

Could you try to provide a simpler example then the one you posted in #242 (comment) please ? I'm not really in favor of using this._module.issuer within the loader if avoidable and would like to triage alternative implementations first (if available)

[claudiocantara]

I created a repository with a project that uses this functionality.
https://github.com/claudiocantara/file-loader-project-test.git

there's have two npm script , start and start:error.
start , provides my solutions while start:error is using 'useRelativePath'.

PS: You will not pass the entire object this._module.issuer , only the ressorce (this._module.issuer.ressource)

[claudiocantara]

Hello, any news on that ?

[alexander-akait]

Better send second params this and you can inside you code what you need, it is universal solution.

[claudiocantara]

The proposal is to know what is the path of the resource that called the loader. With this information any developer will get to know the level of the tree of the origin file and adapt the output path according.

[michael-ciniawsky]

Closing in favor of #166, see #242 (comment)

Feel free to reopen and implement the logic in #166 within this PR :)