As recommended here https://github.com/github/vscode-codeql/pull/1369#issuecomment-1142418037, we want to stay in sync with the current node version shipped with
VSCode (v16.13.0):
32d40cf44e/remote/.yarnrc (L2)
For this we can add a `.nvmrc` file to alert nvm to switch to the preferred version automatically.
It will also help prevent builds from failing when setting up the project for the first time, as building the extension currently fails in Node v18: https://github.com/github/vscode-codeql/issues/1373
We're also updating the docs to mention using `nvm` to manage node versions and point to the right place to check for current supported versions.
Create the `time.ts` module as a place to put fime functions.
Move two time functions there and create tests for them.
The `humanizeUnit` function now uses ECMAscript apis. This ensures
that pluralization happens appropriately.
Also, fix a small bug in the results view to enure `repository`
is correctly pluralized.
The `lastUpdated` value is now the duration between timestamp of the
last time the repo was updated and time the file was downloaded.
This fixes the duration and it won't change over time.
1. Refactor references of `Stargazers` to `RepositoryMetadata` since
the query is now more generic.
2. Update the graphql query to request last updated as well as stars
3. Update web view to display last updated
4. Update sort mechanism for last updated
A few notes:
1. I used `Intl.RelativeTimeFormat` to humanize the times. It wasn't as
simple as I had hoped since I need to also make a guess as to which
unit to use.
2. The icon used by last updated is not quite what is in the wireframes.
But, I wanted to stick with primer icons and I used the closest I can
get.
3. The last updated time is retrieved when the query is first loaded
into vscode and then never changes. However, this time is always
compared with `Date.now()`. So, opening the query up a week from now,
all of the last updated times would be one week older (even if the
repository has been updated since then).
I don't want to re-retrieve the last updated time each time we open
the query, so this timestamp will get out of date eventually.
Is this confusing as it is?
The new support will be available in the next
release of the CLI, most likely 2.9.3,
This change requires the query to be run to be
passed in to the call to resolve ml-models.
