Use a new flag `--npm-publish` in conjunction with `publish` action,
so that the default will always be to `npm pack` if the new flag is not
specified. This flag is also guarded in the actual npm publish code to
ensure that it can only run in the appropriate CI alpha/beta/stable
environment, and not in local or test.
This then also removes the separate `pack` action.
Also removes legacy boilerplate from a number of build scripts.
Note: there is a bit of potential confusion about the difference between
/resources/builder.inc.sh (the full implementation for builder scripts),
and /resources/build/builder.inc.sh (the source script that builder
scripts should always use).
This allows us to make assumptions that will always be true for builder
scripts that may not be true for other scripts, such as setting base
folder.
Fixes#11324.
* Always `cd "$THIS_SCRIPT_PATH"`
* Remove unnecessary `cd` from all build.sh
* Remove unnecessary `set -eu` from all build.sh (and `# set -x`)
* Replace old build-utils.sh incantation in a few build.sh scripts
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 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.
...
```
Part of #9266.
Also cleans up filenames for hint_language_tag_is_not_minimal, and fixes
a bug in transformKpsToKmpObject where a null object could be passed on
to another function in case of failure.
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#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#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.
Replaces kmcomp's package installer build infrastructure. While this is
mostly legacy, package installers are still used in adhoc distribution
scenarios, so we need to continue to support with the new kmc.
The package installer is a Windows self-extracting zip archive. The user
is expected to find setup-redist.exe and keymandesktop.msi themselves,
from the Keyman Developer release files. They are not included with
Keyman Developer, but are available as standalone downloads from
https://downloads.keyman.com/windows/.
`kmc build` has been updated to include two subcommands:
* `kmc build ldml-test-data`
* `kmc build windows-package-installer`
Both of these subcommands are a little long, but the use cases for them
are fairly narrow, so I believe this is okay. `kmc build-test-data` has
been removed, as `kmc build ldml-test-data` replaces it.
Also fixes a file reference issue in kmpJson.options, where paths were
stripped too early in the process.
Removes a now-irrelevant unit test for keyboard_info.
TODO: markdown to html during the keyboard_info build.
Adds license file to .kps, kmp.json, kmc-package, package editor, and
new project templates. The intent is for LICENSE.md to be the file used,
and for any keyboards on keymanapp/keyboards, it should always be a
standard MIT license.
While a package supports a .ttf or .otf font for the OSK and Display
fonts for use within the Keyman apps, on websites it also supports .woff
and .woff2. This change makes it possible to specify a set of fonts for
a package which will be provided through api.keyman.com to websites.
This means that .woff and .woff2 fonts may also be included in the
package and may not be used on target devices at this time, it further
opens the pathway to deploying .kmp packages to web in the future.
The deployment stage of keymanapp/keyboards will require a new phase to
copy web fonts from packages to s.keyman.com.
Adds relatedPackages support to:
* .kps schema
* .kps file format for Typescript
* kmp.json file format for Typescript
* kmc-package compiler
* Package Editor
