Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Request: Destination path pattern #438

Open
TristanApc opened this issue Feb 1, 2019 · 2 comments
Open

Request: Destination path pattern #438

TristanApc opened this issue Feb 1, 2019 · 2 comments

Comments

@TristanApc
Copy link

It would be incredibly useful to support some kind of pattern for the destination path. This would result in less error prone writing of libman.json and could make the migration to LibraryManager faster. In the context that I just performed a migration from Bower and most of the libraries that was in used in the project had a common, yet unique destination pattern.

For example, if you have dozens of libraries that you each want to put in a path of the following format:

wwwroot/lib/{nameOfLibrary}/dist at the moment you have to write the destination for every libraries since you can't use the defaultDestination as every destination are unique.

Minimal repro steps

libman.json with the following contents.

{
  "version": "1.0",
  "defaultProvider": "cdnjs",
  "destinationPattern": "wwwroot/lib/{library}/dist/"
  "libraries": [
    {
      "destination": "wwwroot/lib/eonasdan-bootstrap-datetimepicke/build/"
      "library": "eonasdan-bootstrap-datetimepicker@4.17.47"
    },
    {
        "library": "jquery@2.1.4"
    }
  ]
}

Expected result

A destination of the following form:

wwwroot/
     lib/
          eonasdan-bootstrap-datetimepicker/
               build/
                    ......

          jquery/
               dist/
                    ......

@RobJohnston
Copy link
Contributor

Duplicate of #57 , but this has a better description.

@CodeChief
Copy link

Any progress on this. Seems like a pretty basic feature to implement. Having all the scripts and content from libraries dumped in the same path will surely lead to naming conflicts besides looking like a big mess.

Is this tool still in active development???

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants