Fixing up a number of minor bits and pieces identified during demo:
* invalid action or :target would not be picked up if paired with a
valid one (e.g.: build:foo should not have worked)
* colors defined in both shellHelperFunctions and build-utils were
problematic; able to remove them from shellHelperFunctions because
all references included both scripts
* builder_has_action and builder_report now allow both `action:target`
and `action :target`
* keyman-version/build.sh did not have working test action...
This change also slightly modifies `echo_heading` and outputs a
mark. This will show to the left of the line as well as in the
scroll bar in a terminal in VSCode [[1]] and will help to find the
headings if you have a lot of output in between.
[1]:https://code.visualstudio.com/updates/v1_69#_setmark-sequence-support
Fixes up scripts (except under /linux) to use `#!/usr/bin/env bash`
instead of `#!/bin/bash` or `#!/bin/sh` so that we don't end up with
the ancient version of bash supplied with macOS.
This became urgent with this PR, because of bash-4.xisms in
build-utils.sh, for example on line 572:
```
if [[ -v _builder_params[$e] ]]; then
```
Fixes#6320.
Part 1 of moving from lerna to a simpler, maintained monorepo solution,
using TypeScript Projects and NPM Workspaces.
There is more work to be done here. At this point, KeymanWeb builds and
runs without errors, but the built file is substantially different,
mostly in include order.
Using TypeScript Projects, we move away from the need to run build
scripts in various locations for almost all the Typescript modules.
TODO: Embedded versions and tests have not been verified.
TODO: developer/server is not yet verified.
TODO: developer/js (needs a rename!) is not yet verified.
TODO: Currently, the predictive-text folder needs refactoring to move
the construction of the worker wrapper out of the Predictive Text build
and into the final assembly of keymanweb.js (as it should be valid to
run it as a separate .js anyway).
TODO: Most of the `<reference>` paths need to be re-verified. Ideally
there should be no references outside the current module for any given
.ts.
TODO: The embedded vs browser vs node (headless) builds should be tidied
up for consistency so that it's obvious what depends on what. This is
currently messiest in the predictive-text folder, where the output names
diverge from the filenames and the various files are mixed in the same
folder (as evidenced by the exclusions listed in each tsconfig.json).
TODO: `npm install` should be removed from most build scripts and
instead `npm ci` (#6196) should be run only once from the top-level
folder for any given build. I've had eliminated side-effects from the
`install` action for npm, which makes it easier to reason about state.
TODO: verify_npm_setup and related functions can probably be eliminated.
TODO: most of the build scripts should be largely eliminated for web.
TODO: several ts projects use inconsistent output folders.
TODO: it may be possible to generate a .d.ts for models/types so that
we can use a consistent reference for those as well.
TODO: build.sh, tsconfig.json should always be in the module's top-level
folder, not in a subfolder such as src (e.g. see input-processor/src,
keyboard-processor/src, web/source).
TODO: resources/web-environment should be in common/web.
TODO: other js node_modules imports should be wrapped like es6-shim.
TODO: fix up the publish code for npm modules
TODO: eliminate version numbers from package.json if possible?
Whew, that's most of the stuff I noticed!
Some of the global color variables in shellHelperFunctions.sh were a
little dangerously named. This cleans that up and removes a couple of
redundant functions from other locations.
mac/bashHelperFunctions.sh should be removed and replaced with
references to shellHelperFunctions.sh -- but I wanted to leave that for
a separate branch.
1. Renamed form UfrmNGrokOptions to UfrmServerOptions
2. Renamed kmdev-server to just plain server
3. Tidied up npm versioning to use VERSION_WITH_TAG
This last point should help avoid confusion as now only CI release
builds will ever generate a package.json with a.b.c, a.b.c-alpha or
a.b.c-beta. Local and test builds will always have the corresponding
-test or -local environment appended. This also helps avoid issues if
we accidentally publish an incorrect version.
