Moved all configuration logic into createConfig.mjs, which validate and returns config. Note:

1. I added config file validation using a combination of
ts-json-schema-generator (to generate a JSON schema from the ConfigFile
type) and ajv (to validate that the config file matches it). This way
we don’t need to include a bunch of custom validation logic for each
config property.

One trade-off here is that SmartDialerConfig isn’t based on the
underlying Go code, so it could fall out of sync.

If we convert all the scripts to TypeScript we can replace this with
e.g. zod or ts-pattern (which I’m familiar with) by starting with a
pattern and deriving both a type and validator function, rather than
starting with the type and deriving a validator function.

2. To simplify things I made a decision to only accept two CLI
arguments: config (for passing in custom config locations) and platform
(to choose build platform without creating redundant platform-specific
configs). This sidesteps the issues with e.g. passing in
additionalDomains (do we accept a comma-separated list?) and
smartDialerConfig (do we accept a JSON string then parse it?).

3. There are still two types: Config and ConfigFile. ConfigFile (used
for config file validation) is based on Config, but with derived
properties (entryDomain, domainList, and smartDialerConfigBase64)
removed, and the remaining properties other than entryUrl optional.

I don’t see any way to avoid this unless we require that the config file
contains all config properties (including the derived properties).

Also note that I renamed these from "BuildConfig*" to "Config*". I think
"Config" conveys "app maker config" given the name of the project, and
having "build" or "make" in the type name might be more confusing since
both could be read as a verb.

4. I tried replacing the derived properties with getters as suggested in
[1], but to be compatible with the Handlebars template compilation [2]
I think we would need to add a custom toJSON method to the class for
the derived properties, which was making the class increasingly harder
to read and understand vs. just outputting a config object including
the derived properties as I did. IMO this is an acceptable trade-off
given the config object isn’t really a user-facing thing, but let me
know if there’s a better way here.

[1]: #8 (comment)
[2]: https://github.com/Jigsaw-Code/outline-app-maker/blob/7fa63ea3539a105e66d8ee43791166ed21c5bef9/wrapper_app_project/scripts/build.mjs#L107-L114

Author: GrantASL19

.gitignore

@@ -1,5 +1,6 @@
 .DS_Store
 .vscode/
+config.yaml
 output/
 node_modules/
 tsconfig.tsbuildinfo

config-sample.yaml

@@ -0,0 +1,13 @@
+additionalDomains:
+  - medium.com
+appName: 'Jigsaw'
+entryUrl: 'https://jigsaw.google.com'
+smartDialerConfig:
+  dns:
+    - https:
+        name: 9.9.9.9
+  tls:
+    - ''
+    - split:1
+    - split:2
+    - tlsfrag:1

config.yaml

@@ -2,11 +2,13 @@
   "name": "outline-app-maker",
   "dependencies": {
     "@ngrok/ngrok": "1.4.1",
+    "ajv": "^8.17.1",
     "archiver": "^7.0.1",
     "chalk": "^5.4.1",
     "http-proxy": "^1.18.1",
     "minimist": "^1.2.8",
     "serve-handler": "6.1.6",
+    "ts-json-schema-generator": "^2.4.0",
     "yaml": "^2.7.1"
   },
   "devDependencies": {

package-lock.json

@@ -10,7 +10,7 @@
     // We only use TSC for checking .mjs files
     "noEmit": true
   },
-  "include": ["**/*.cjs", "**/*.mjs", "**/*.js"],
+  "include": ["**/*.cjs", "**/*.mjs", "**/*.js", "**/*.ts"],
   "exclude": [
     "basic_navigator_example", // TODO: Remove this exclusion?
     "node_modules",