Adds warning and docs to let users know when they're running in ARM
translation mode. Also lets them configure to always dismiss if they
don't care.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Added a configuration option to dismiss architecture warnings during
application startup.
- Introduced new FAQs addressing ARM64 translation warnings and
instructions for joining beta builds.
- Added platform-specific requirements for macOS, Windows, and Linux in
the getting started documentation.
- **Bug Fixes**
- Enhanced build command flexibility by allowing dynamic command-line
arguments during the build process.
- **Documentation**
- Updated configuration documentation to include the new dismiss
architecture warning key.
- Minor formatting adjustments in FAQs and getting started
documentation.
- Clarified platform compatibility details in the README.
- **Chores**
- Added a new constant for the dismiss architecture warning
configuration key.
- Introduced a new field for managing architecture warning settings in
the application configuration.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Going forward for new installations, config and data files will be
stored at the platform default paths, as defined by
[env-paths](https://www.npmjs.com/package/env-paths).
For backwards compatibility, if the `~/.waveterm` or `WAVETERM_HOME`
directory exists and contains valid data, it will be used. If this check
fails, then `WAVETERM_DATA_HOME` and `WAVETERM_CONFIG_HOME` will be
used. If these are not defined, then `XDG_DATA_HOME` and
`XDG_CONFIG_HOME` will be used. Finally, if none of these are defined,
the [env-paths](https://www.npmjs.com/package/env-paths) defaults will
be used.
As with the existing app, dev instances will write to `waveterm-dev`
directories, while all others will write to `waveterm`.
Adds new functionality on the backend that will merge any file from the
config directory that matches `<partName>.json` or `<partName>/*.json`
into the corresponding config part (presets, termthemes, etc.). This
lets us separate the AI presets into `presets/ai.json` so that we can
add a dropdown in the AI preset selector that will directly open the
file so a user can edit it more easily. Right now, this will create a
preview block in the layout, but in the future we can look into making
this block disconnected from the layout.
If you put AI presets in the regular presets.json file, it will still
work, since all the presets get merged. Same for any other config part.
This will take the latest artifact from the waveterm-docs repo and embed
it in the app binary. When the help view is launched, it will be served
from our backend. If the embedded copy doesn't exist, such as in
unpackaged versions of the app or in locally packaged versions, it will
use the hosted site instead.
There is a sibling PR in the docs repository to build the embedded
version of the app (strips out some external links, removes Algolia
DocSearch, updates the baseUrl)
https://github.com/wavetermdev/waveterm-docs/pull/46
This change shaves ~20 MB off the download size by only copying over the
wavesrv binary that is relevant for whichever architecture we're
currently packaging. This is only relevant for macOS at the moment,
though it can also apply to Windows when we get multi-arch builds
working.
This required renaming our Go binaries from .amd64 to .x64 to comply
with electron-builder's naming conventions.
With this PR, Electron will generate a new authorization key that the Go
backend will look for in any incoming requests. The Electron backend
will inject this header with all requests to the backend to ensure no
additional work is required on the frontend.
This also adds a `fetchutil` abstraction that will use the Electron
`net` module when calls are made from the Electron backend to the Go
backend. When using the `node:fetch` module, Electron can't inject
headers to requests. The Electron `net` module is also faster than the
Node module.
This also breaks out platform functions in emain into their own file so
other emain modules can import them.
