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.

Sign up for GitHub

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

Jump to bottom

Library Default Destination #68

Closed
tb-mtg opened this issue Apr 19, 2018 · 1 comment · Fixed by #759
Closed

Library Default Destination #68

tb-mtg opened this issue Apr 19, 2018 · 1 comment · Fixed by #759

Comments

@tb-mtg
Copy link

tb-mtg commented Apr 19, 2018 •
edited
Loading

Instead of specifying the destination of each library, is it possible to introduce a new "default destination" setting that uses conventions at the top level of libman.json. This setting would still be able to be overwritten at each library level.

For example:

  • twitter-bootstrap version 3.3.7 library would go to wwwroot/lib/bootstrap
  • jquery version 1.12.0 library would go to wwwroot/lib/jquery/1.12.0
  • jquery version 3.3.1 library would go to wwwroot/lib/jquery/3.3.1

the libman.json would look something like this:

{
  "version": "1.0",
  "defaultProvider": "cdnjs",
  "defaultDestination": "wwwroot/lib/[LibraryName]/[Version]",
  "libraries": [
    {
      "library": "[email protected]",
      "destination": "wwwroot/lib/bootstrap"
    },
    {
      "library": "[email protected]"
    },
    {
      "library": "[email protected]"
    }
  ]
}

Thanks
@nickalbrecht
Copy link

nickalbrecht commented Apr 19, 2018 •
edited
Loading

You likely wouldn't want to introduce version number into your file names/path as each update would break all of your references unless you're using wildcard/masks, but that's up to the each person who comes up with the their own default path. But it would be nice to expose a way to inject certain pieces of information from the library into the path using tags in the defaultDestination. [Name] and [Version] would be easy as both are properties hanging off of the ILibrary interface. Probably a good idea to sanitize the name/version before use though, just in case there are characters that are invalid for a path.

jimmylewis added a commit to jimmylewis/LibraryManager that referenced this issue Jun 1, 2024
@jimmylewis
Add variable expansion in defaultDestination
c929c6b 
This implements aspnet#68, except I used [Name] instead of [LibraryName].  It felt like LibraryName should be matched with LibraryVersion and that felt verbose, so I took the shorter versions.

This expansion is applied when we expand the ManifestOnDisk (which is either read from disk or from a raw JSON) into LibraryInstallationState.  This is where we determine to use the defaultDestination or a library-specific destination, so it should be the only place this expansion needs to occur.
@jimmylewis jimmylewis mentioned this issue Jun 1, 2024
Merged
jimmylewis added a commit to jimmylewis/LibraryManager that referenced this issue Jun 2, 2024
@jimmylewis
Add variable expansion in defaultDestination
ff5e6f5 
This implements aspnet#68, except I used [Name] instead of [LibraryName].  It felt like LibraryName should be matched with LibraryVersion and that felt verbose, so I took the shorter versions.

This expansion is applied when we expand the ManifestOnDisk (which is either read from disk or from a raw JSON) into LibraryInstallationState.  This is where we determine to use the defaultDestination or a library-specific destination, so it should be the only place this expansion needs to occur.
jimmylewis added a commit to jimmylewis/LibraryManager that referenced this issue Aug 4, 2024
@jimmylewis
Add variable expansion in defaultDestination
d252a09 
This implements aspnet#68, except I used [Name] instead of [LibraryName].  It felt like LibraryName should be matched with LibraryVersion and that felt verbose, so I took the shorter versions.

This expansion is applied when we expand the ManifestOnDisk (which is either read from disk or from a raw JSON) into LibraryInstallationState.  This is where we determine to use the defaultDestination or a library-specific destination, so it should be the only place this expansion needs to occur.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Add variable expansion in defaultDestination jimmylewis/LibraryManager
2 participants
@nickalbrecht @tb-mtg