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.
I missed adding this as a dependency for @keymanapp/kmc-package. because
node has a very lenient dependency search, it found xml2js from other
@keymanapp/common-types, so never caused errors locally.
Fixes#9266.
For historical reasons there are many non-minimal BCP 47 tags in package
metadata in the repository (over 2500). Furthermore, earlier versions of
kmcomp did not fail the build on package compilation warnings. This
means it is better to reduce WARN_LanguageTagIsNotMinimal to
HINT_LanguageTagIsNotMinimal, so that we can otherwise respect the
'treat warnings as errors' flag on the keyboard projects.
We may be able to upgrade this to a warning again one day 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#9478.
This adds a property WelcomeFile to .kps and kmp.json, which allows us
to move away from the hardcoded welcome.htm filename in the future, and
makes transform from Markdown (#9477) a simpler operation, and just
generally starts the cleanup of the messiness of hard-coded filenames.
The package compiler will fallback to injecting welcome.htm into this
property if (a) welcome.htm is present, and (b) the property does not
already have a value. This doesn't buy us much because we still need to
support welcome.htm for existing legacy packages, but does mean that
our .kmp package metadata will be more consistent for packages compiled
with 17.0+ compilers.
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#9672.
Also rewrote build.sh as a builder script in order to simplify some of
the build changes.
Makes /web a dependency of Keyman Developer Server, which is a
significant improvement, but we need to consider if we want to use web's
debug build as we did in the past.
Fixes#9324.
As .js keyboards in packages are only used by the iOS and Android apps,
it's kinda helpful if the keyboard itself includes a touch layout. While
Keyman will fall back to a desktop vk layout if a touch layout is not
present, this is less than ideal -- but that's why this is setup as a
hint and not a warning.
Fixes#9325.
Also tweaks test for error_package_must_contain_a_model_or_a_keyboard as
the fixture had a .kmn, triggering the new hint, which was unhelpful in
this case.
Fixes#9541.
Also adds version 16.0 support to the kmcmplib compiler constants, and
unit tests for both versions. Does not add any support for automatic
version feature detection, because that forces an inverted dependency on
the touch layout compilation phase (done in kmc-kmw), which would be a
significant refactor. This may be something we need to support in the
future.
Fixes#9610.
If a build fails when "treat warnings as errors" is on, but there are
only warnings and no error messages, it can be confusing for the
developer. Adds the following `INFO_WarningsHaveFailedBuild` message:
`The build failed because option "treat warnings as errors" is enabled
and there are one or more warnings.`
