Establishes keyman-urls.ts as a single place for any links to external
websites.
I searched all .ts files in Keyman Developer source and replaced
references to websites with function calls here. Note that the names of
individual functions within this class can be easily changed as needed,
as the hard part was the consolidation.
Realtes to #10207.
Adds a new `kmc message` command which prints detailed information about
any or all compiler messages, in JSON, text, or markdown formats.
Markdown format is emitted to file in a structured way to be deployed to
the help site automatically (coming in a subsequent commit).
Moved the ERROR_Message line above the Error_Message line for every
message in the compiler message files, as it makes the grouping clearer
once we start adding message details. For example, see the start of the
KmnCompilerMessages class.
Also wraps potentially-undefined parameters to the messages with a new
function `def`, shorthand for `CompilerMessageDef`, which converts the
parameter to '<param>' if it is undefined, which is helpful for
documentation.
Relates to #10207.
In order to include message detail in messages, it is helpful to split
out the exception messages which have a separate parameter, so that
parameter at the same position can be the message detail.
Introduces the CompilerMessageSpecWithException function which takes an
exceptionVar parameter to achieve this differentiation.
Relates to #10207.
Adds the `api` action to build.sh for each affected module. The `api`
action for each module will generate the api metadata files, and then
the markdown files are generated by /developer/build.sh api.
Note that developer-utils, kmc, and kmcmplib have no api documentation
at this time (and kmcmplib is not Typescript so would need separate
tooling anyway).
Relates to #10207.
Adds @microsoft/api-extractor and @microsoft/api-documenter NPM
packages for validating and generating API documentation from Typescript
modules.
Adds basic configuration for each module that we will be publishing at
this time.
api-extractor's output will be emitted to /developer/docs/api/etc/, for
future release comparisons. A baseline output will be committed
separately.
The build outputs will be in /developer/build/docs and the intermediate
files will be in /developer/build/api.
Note that at this time, we will not enable the checks and validations.
That is a task for alpha rather than beta. The primary intent at this
time is to select a solid, well-supported toolchain for generating the
API documentation for kmc.
Relates to #10150. Makes the various Messages classes in kmc modules
accessible to other modules. Some file renames involved to reduce
confusion.
No functional changes.
Fixes kmc-analyze metadata.
See #10254 for a related future fix.
Relates to #9473.
Refactors the public API of KeyboardInfoCompiler to meet KeymanCompiler,
including moving file write responsibilities into the class itself.
`sources` has become a property of `options`, which is perhaps a slight
violation of the intent of the `init()` function being a one-time call,
as it means we'll need to instantiate an new class for each file we
compile. Given the use-case for the keyboard_info compiler is almost
exclusively internal, I think this is acceptable. Tell me if you think
otherwise!
Relates to #9473.
Refactors the public API of PackageCompiler and
WindowsPackageInstallerCompiler to meet KeymanCompiler, including
asyncing a bunch of functions, and moving file write responsibilities
into the classes themselves.
The classes were updated together in a single commit because
WindowsPackageInstallerCompiler depends on PackageCompiler, and needed
refactoring for the updated API access there anyway.
Most of the test cases needed only minor patching, but introducing the
`async init()` function has caused them to all be async. The
test-messages module has a slight functional change with the compile
process running completely rather than stopping on first message, which
meant we needed to add extra dummy fixtures to avoid other errors that
arose later in the compile process. The keyman.exe fixture is a text
file, not a Windows executable.
Given we've just run a build, this (a) seems unnecessary, and (b) seems
to go wrong in some circumstances anyway, e.g.
https://build.palaso.org/buildConfiguration/Keyman_Developer_Release/421326?buildTab=log&focusLine=19936&linesState=18839&logView=flowAware:
```
07:01:29 > @keymanapp/kmc@17.0.205-alpha prepublishOnly
07:01:29 > npm run build
07:01:29
07:01:31
07:01:31 > @keymanapp/kmc@17.0.205-alpha build
07:01:31 > tsc -b
07:01:31
07:01:35 ../../../common/web/types/build/src/kmx/kmx.d.ts(1,1): error TS1036: Statements are not allowed in ambient contexts.
07:01:35 ../../../common/web/types/build/src/kmx/kmx.d.ts(1,2): error TS1345: An expression of type 'void' cannot be tested for truthiness.
...
```
Instead of generating a name for the web fonts, we should be using the
font family from the .ttf, as we have it available. This allows us to
avoid downloading the font if the user already has it installed on their
system.
Uses ttfmeta npm package, which is a lightweight .ttf reader. Updates
the honking big unit test to do some basic tests on this functionality.
The new --for-publishing flag allows us to enforce additional
requirements for keyboards and lexical models that are to be published
to the keymanapp repositories. This flag will always be switched on in
the repository builds. This flag overrides the 'skipMetadata' option
which is a project-level option.
There is a bit of a delicate balance of requirements here:
1. We want to be able to automatically verify keyboards and package
licenses if they are in the repository.
2. We do not want to force license checks on privately built keyboards
and models.
3. We want to provide pathways for users to check locally before
submitting to the repository.
4. If possible, we want to be able to build the .keyboard_info and
.model_info files locally, but this should be up to the user for
local builds.
For now, the only additional check that this flag provides is to verify
that the license is MIT, which was an unchecked requirement for the
repositories in the past.
Future checks can be added for file layout, additional required
metadata files.
Anticipate adding this as a tool to Keyman Developer IDE -- a
'pre-publish' check -- in the future.
Fixes#9708.
Matches the kmp.json format of keys string in the .keyboard_info schema
and compiler, in order to reduce the number of formats we are working
with. This same format may be used elsewhere in Keyman schemas in the
future for sets of keys, for example, I hope we can use it in regression
tests.
Fixes#9640.
This ended up being somewhat more fragile than originally anticipated.
For the `ajv` cli call to get the right versions, we needed to install
ajv as a dev dependency in the top-level package.json as well as at the
common/web/types level.
Ajv does not do all that well with ESM yet, either, so we use esbuild to
transform the compiled validators before building in typescript.
Fixes#9620.
.keyboard_info keys emitted from kmc-keyboard-info had the wrong format
for the example.keys object, which I discovered when I applied the
validation to the kmc-keyboard-info output.
