Can't specify destination folder for library!

[Joebeazelman]

Libman doesn't support the concept of moving files, which makes it unusable! In my configuration file below, the entire folder hierarchy in the PopperJS folder. All I want to do is copy dist/popper.js to PopperJS to get the following:

\PopperJS

• popper.js

Instead I get this: \PopperJS \dist -popper.js",

There's no way to specify moving the file to the root. Instead, it creates the "dist" folder. If you try to remove the "dist" from the "files", it won't find the file in the package. Is there a way to specify the final directory?

{ "provider": "unpkg", "library": "popper.js@1.14.2", "destination": "Themes/Vigoda/Content/PopperJS", "files": [ "dist/popper.js", ] }

[nickalbrecht]

The only time this tends to come up, in my experience, is when your package source has a full project structure and not just the distribution folder. In a normal resource, altering the full path can break resources like CSS, graphical assets like fonts, images, etc. I believe this is why it doesn't let you alter the full path to an item (I'm guessing). I get the same problem when importing signalr which I import like this

    {
      "provider": "unpkg",
      "library": "@aspnet/signalr@1.0.2",
      "files": [
        "dist/browser/signalr.min.js",
        "dist/browser/signalr.js"
      ],
      "destination": "wwwroot/vendor/signalr"
    }

Unfortunately even if you are cognizant of this path caveat, libman doesn't stop holding your hand and let you override this behavior. So I believe until a way is provided to indicate "no, it's ok, I know what I'm doing" you're stuck with your asset paths looking like the following, even though I care nothing of the dist or browser path segments.

    <script src="~/vendor/signalr/dist/browser/signalr.js"></script>

[Joebeazelman]

Fair enough, but why can't it do something like the following:

{
  "provider": "unpkg",
  "library": "@aspnet/signalr@1.0.2",
  "files": [
    "dist/browser/signalr.min.js",
    "dist/browser/signalr.js"
  ],
  "destination": "wwwroot/vendor/signalr"
  "src_dest_map":  [{ "dist/browser/":"" }]
}

In the snippet above, you can just map your source directory to destination directory. If fact, you could even allow individual files to be mapped and even renamed.

[nickalbrecht]

There're many potential for ways it could be implemented, for sure. It just doesn't currently as far as I know. Mostly likely because of the complexity of someone inevitably wanting to change the mapping on a per file bases.

[jimmylewis]

I think this came up in another issue as well, and what I'd like to see is something along these lines, to allow you to be more expressive for each file.

{
  "provider": "unpkg",
  "library": "@aspnet/signalr@1.0.2",
  "destination": "wwwroot/vendor/signalr",
  "files": [
    // no change from today if specified as a string.  This would yield dist/browser/signalr.js
    "signalr.js",
    // allow customizing the path relative to "destination" above.
    { "dist/browser/signalr.min.js": "min/signalr.min.js"}, 
    // or even the file name.
    { "dist/browser/foo.js": "bar.js"}
  ]
}

[nickalbrecht]

I fully expect the next thing that will be asked for is widcards and/or globs. So it's a slippery slope for what starts out as a pretty innocent request.

[arogers-enthink]

Wherever you lean on the idea bundling of CSS/JS given HTTP/2 exists.. if you are bundling then this in-ability to define output locations per-file really hurts.

If you are using a library such as:

        {
            "library": "bootstrap-icons@1.4.1",
            "destination": "wwwroot/lib/bootstrap-icons/",
            "files": [
                "font/fonts/bootstrap-icons.woff",
                "font/fonts/bootstrap-icons.woff2",
                "font/bootstrap-icons.min.css"
            ]
        },

Here, the vendor's CSS file naturally has @import url(fonts/bootstrap-icons.... So if you want to bundle all of the wwwroot/lib/**/*.css files and dump that in wwwroot/css you now have some 404 on getting those font files [because they are in wwwroot/lib/bootstrap-icons/font/fonts/]. Of course this is a personal problem / implementation issue, but can't it be something simple like adding this to the API:

        {
            "library": "bootstrap-icons@1.4.1",
            "destination_files": [
                { in: "font/fonts/bootstrap-icons.woff", out: "wwwroot/fonts/" },
                { in: "font/fonts/bootstrap-icons.woff2", out: "wwwroot/fonts/" },
                { in: "font/bootstrap-icons.min.css", out: "wwwroot/lib/bootstrap-icons/" },
            }
        },

Keep your current "destination" property/API, but add something new that by default only "remembers" the filename.

[ssg]

This was the most common problem with NuGet managed JS packages. Why have a new package management mechanism if it doesn't fix the problems of an existing one?

[mythz]

When most npm packages publish their assets in a /dist/ folder it seems very lacking not to have some way to remove it from the destination directory, also many times the names used for their builds aren't the names you would want in your project which becomes a non-starter for TypeScript definitions where you need precise control over their destination file names.

This feature could be easily be implemented using a simple dictionary mapping like:

{
  "provider": "unpkg",
  "library": "vue@3",
  "filesMap": {
    "dist/vue.esm-browser.js": "vue.js",
    "dist/vue.esm-browser.prod.js": "vue.min.js"
  },
  "destination": "wwwroot/lib/vue/"
}

Anyway the lack of this feature makes libman unusable for use in our project templates and we've had to resort to implementing downloading of assets in a custom node .js script.

[lonix1]

This is also counter to the documentation, which clearly shows that the package's own directory structure is ignored.

So either the library or docs should be fixed. I've reported the docs error here.