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

Library Default Destination #68

Open
tb-mtg opened this issue Apr 19, 2018 · 1 comment · May be fixed by #759
Open

Library Default Destination #68

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

Comments

@tb-mtg
Copy link

tb-mtg commented Apr 19, 2018

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": "twitter-bootstrap@3.3.7",
      "destination": "wwwroot/lib/bootstrap"
    },
    {
      "library": "jquery@1.12.0"
    },
    {
      "library": "jquery@3.3.1"
    }
  ]
}

Thanks

@nickalbrecht
Copy link

nickalbrecht commented Apr 19, 2018

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
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 linked a pull request Jun 1, 2024 that will close this issue
jimmylewis added a commit to jimmylewis/LibraryManager that referenced this issue Jun 2, 2024
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
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
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants