The `logging` part of `common` was exported in `common/index.ts` and
could be imported by importing `common`. I don't think this makes a lot
of sense, so I removed it.
The `common/logging/index.ts` also contained exports of the
`common/logging/vscode` directory, which means that importing
`common/logging` automatically brings in the `vscode` module. This
removes that export, so now there are two separate imports needed for
importing the common part and the `vscode` specific part. This should
make it easier to keep them separate and be more explicit about what
you're importing.
This moves the `showAndLog` family of functions to the `common/logging`
directory. It explicitly moves the `showAndLogExceptionWithTelemetry`
function to the `common/vscode/logging.ts` file because it still has a
dependency on the `telemetryListener`, which depends on the `vscode`
module.
This will make both the `askForLanguage` and `findLanguage` functions
return a `QueryLanguage` instead of a `string`. This will make it harder
to make mistakes when using these functions.
There are also some other changes with regards to `QueryLanguage` such
that we never need to use `as QueryLanguage` explicitly anymore, except
for the new `isQueryLanguage` function. The only remaining place that I
know of where we're using a `string` to represent the `QueryLanguage`
is in a database item's language, but this is harder to change and may
be relied upon by language authors.
This adds the external API query text to the extension directly to avoid
users having to copy the query to their local `codeql` submodule or
having to checkout a specific branch.
This is a temporary solution until the queries are stabilized. Once they
are, we will upstream these to `github/codeql` and use them like other
contextual queries.
Since this is just a temporary solution, this is not the prettiest code
and is not intended to be a long-term solution. It does not do proper
caching and will create a new temporary directory for every query run.
The performance hit of this is acceptable and expected.
The data extension editor was only using the default data extensions
found in the `ql` submodule to find external API calls. This will add
support for using data extensions found in the workspace.
Rather than using the `codeQL.runningQueries.useExtensionPacks` setting,
this will always include data extensions since the editor doesn't make
sense to use without data extensions. We will also forbid the user from
opening this view unless they are using a CLI which supports data
extension packs.
This adds tests for the external API query and retrieving of results. It
does not use the "real" CLI integration, but instead mocks the CLI
server and query runner.
To make mocking easier and require less type casting, I've narrowed some
of the arguments of some other functions. They now use `Pick` to only
require the properties they need.
