feat(outputPath): add possibility to define output path

[Slashgear]

What kind of change does this PR introduce? (bugfix, feature, docs update, improvement)

• Add possibility to define output path.
• Add documentation

What is the current behavior? (You can also link to an open issue here)

We could only define a public path (ie: Browser path to get the generated file)

What is the new behavior (if this is a feature change)?

• Be able to store sprite in a different path from it's accessible path With webpack, concepts of outputPath and publicPath are different. This allows you to have on the server side a different file structure than the access url. This can be very useful when our server rewrites the urls on the fly.

Many loader allow to manage this feature, that's why I suggest it. Does this PR introduce a breaking change?

Nope, made it retrocompatible because this param is not required.

Please check if the PR fulfills contributing guidelines

[kisenka]

@Slashgear thanks for PR! How this option differs from publicPath?

[Slashgear]

@kisenka How this option differs from publicPath?

In webpack world:

• outputPath defines the location of generated chunks in the disk.
• publicPath defines the url path for a User in a browser to fetch the file.

Those two could be the same and you would use only a publicPath, but in some cases, you need to be able to define a different path.

Imagine a webpack generated output like this.

dist/
  public/
     assets/
        sprite.svg
  server.js

I want to generate an output file in the public/assets/sprite.svg path but I only want to open public files to the web by rewriting URL in order to hide my server.js file.

You would use

{
  "outputPath":"public/assets/",
  "publicPath":"/assets/",
}

[kisenka]

Got it! Could you please add test case for your changes? It can be based on this one case.

[kisenka]

Shipped in svg-sprite-loader@4.3.0