This implements #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.
The logic had a flaw that it didn't verify the directory separator after the directory portion. NormalizePath strips trailing slashes, so there will never be one. However, for IsUnderRootDirectory, there must be a separator in the path.
* Update package references
Update a number of packages to be more modern
Stop shipping binaries to run in VisualStudio that VisualStudio already ships (With binding redirects/etc.)
Update the SLN file so that the Vsix project is the default startup project.
* Accept code review feedback
The existing LibraryInstallationState abstraction is not flexible about mapping files to their source on an individual basis. It presumes that all files installed by a library retain the same folder hierarchy as the library they originate from.
In order to allow more flexibility, this change adds a new abstraction to wrap all installed files to their individual source files. This eliminates the prior assumption, allowing for flexibility to install files to a different folder hierarchy than their originating library structure.
This flexibility also allows an important new concept: each destination file must be unique (to avoid collisions), but the sources are not so constrained. A single source file may be installed to multiple destinations; by creating a mapping of destination-to-source, we can easily allow this.
This change prepares for a new feature to allow more granular mappings of files within a library.
Currently, unpkg and jsdelivr support using 'latest' as a version. When files are requested by libman, they redirect (HTTP302) to the URL for the current latest files. We put those files into the cache like any other version (in a folder name 'latest') and all is well.
However, when a new version is released, libman continues to use the now-stale downloaded assets from the cache. There isn't a signal to realize when to purge the latest version from the cache.
This change instead simply turns 'latest' into the latest version we determine from the provider. There is a small risk that we are out of sync with the CDN: for example, since we get the version data from NPM, it might not match the version that e.g. jsdelivr redirects to. But this should be extremely rare.
Doing it this way also allows cdnjs to support 'latest'. I didn't add it to the completion items, but I did verify that it works (CLI install, restore, and the file list in VS all support foo@latest for cdnjs now too).
This was designed to return many results, but that doesn't make a lot of sense when installing a single library. Also, the existing code paths only lever returned an enumerable of one item, which is wasteful.
Update Library Manager build for net8
Various fixes to update the LibraryManager repo:
Fix LibraryManager.sln so that it defaults to the vsix project
Extract TFMs that are likely to change into variables
Update to net8
SourceLink is built into net8 SDK, can drop explicit references
Update to net481, including source code references
Change version.json to major version 3.
* Don't write default config file during init
Per #719, this can cause issues with multiple concurrent processes
executing (for example, parallel MSBuild nodes in a solution).
Retrospectively, it doesn't provide anything useful either. It's faster
to just create the defaults in memory than to get file IO involved.
* Updated to latest (17.7 GA) packages from VS
* Addressed some warnings, old and new
* VSTHRD analyzer complaining about unawaited tasks => explicitly discard to indicate fire-and-forget
* OutputWindowPane.OutputString is deprecated => switch to OutputWindowTextWriter, which allows free-threaded writes to an output pane
* Couple integration tests were failing by calling removed APIs => updated to latest (17.7) and tests now pass
* Pinned a few package versions to resolve MSB3277 warnings
* VS JSON parser's ArrayElementNode.Elements marked deprecated => move to ElementNodes.
The Cdnjs API is changing to stop including the assets for all versions of a library in the /libraries/:library API. We were using this to determine both library versions and library files.
The changes are fairly straightforward:
- for versions, we can just use the "versions" property from the library. It's probably easier than what we were doing before (parsing each version from an "assets" entry).
- for files, we need to invoke the /libraries/:library/:version API instead. However, the default file (which we use for selecting the default checked box in the wizard) is on the library group, not the library-version, so we still need to get that from the first request.
- Lastly, I included fields on each API call, so that we're not downloading any data that we aren't intending to use. This drops 10s of KB from most library group queries, since there's a lot of metadata we don't care about. We can always add more back later.
As netcore2.1 is out of support, these tests fail to run on the CI
agents. Updating to net6.0 will allow the tests to continue running.
Updating the src projects to net6.0 would also mean that they would stop
functioning for customers who did not have net6.0 installed. This can
be a concern for both the MSBuild package and the CLI. Such a change
should only be made when we are bumping the major version.
The API call used by the Unpkg catalog only returns the latest release
version. In order to get prerelease versions as well (e.g. for the
Upgrade lightbulb), we need to specifically get all versions.
Addresses #349.
There isn't a guarantee that the data from providers is sorted in the
desired order (e.g. for versions, sorted descending). This change
ensures we sort the completion items before showing them in the search
box flyout.
In the JSON completion scenario (which is similar), each completion item
is instead represented by a CompletionEntry implementation which
implements IComparable<T> for that completion type. The editor
completion stack handles the sorting for us already.
Addresses #531.
This change converts to using the Central Package Version Management
feature in NuGet, enforcing that all PackageReference versions are
tracked in one central place.
I also bumped up the dependencies for most of the packages that we rely
upon.
Code changes are to address new analyzer issues from updating to the
latest analyzer packages.
* fix: provide error message for unknown provider.
If a provider is given and it is not one of the available providers, output an invalid operation message like "Provider 'foo' is not installed.
Closes#134
Cdnjs library metadata used to be returned in order from newest to oldest, but that is no longer the case - now it seems to be alphabetical by version. In many cases, this leads to recommending the oldest version of the library.
There is a "CacheService.cs" file within the "CacheService" directory, so the directory was renamed and a namespace added to match the folder structure.
- Add ConfigureAwait(false) to the files changed in this PR
- Remove unnecessary using in UnpkgCatalogTest
- Remove unused sample string CdnjsProviderTest
This change reduces the repentitiveness of implementing request-and-cache or check-cache-else-request patterns when requesting provider metadata. This simplified code in each provider, and also centralized testing that behavior on the CacheService class rather than duplicating cache behavior testing.
It also removes the GetCatalogAsync and GetMetadataAsync as those names were Cdnjs-specifc, and the catalog is just another form of metadata.
Testing was also largely refactored to apply fakes at the ICacheService layer instead of the underlying IWebRequestHandler, as that should be transparent to the Catalog implementations. There are a couple exceptions to verify that no web requests are issued at all during some test scenarios.
Currently we download these files and cache them locally with a hardcoded lifetime. Once the file is expired, we attempt to download a new copy; however, if that request fails, we just fail the operation. With this change, we'll at least fall back to the already-stored copy, which may be stale but should still work in most cases.
Using mocked out responses instead makes the tests faster and more resilient to network or service provider irregularities.
There are still some tests that invoke code paths using real web requests, those can be addressed in another change.
Ideally these wouldn't make any live web requests, but we don't have that level of DI built into the CLI commands yet (or their tests) yet. Using specific versions will still test the scenarios, but we won't have tests break whenever a new jQuery release is published.
Phil Allen
Jimmy Lewis
Leonid Tsarev
Tomasz Polachowski
Jimmy Lewis
Todd Grunke
Rob Johnston