WebHare libraries are often designed for use in either the frontend (ie bundled in the Javacript code sent with a page) or the backend (as part of a RPC, the generation of a dynamic or static published page or a Tollium application).
Shared libraries
The 'shared' libraries are designed to be used in both frontend and backend
@webhare/env: The WebHare 'environment', eg the debug flags and version information. This library works in both frontend and bakend but specifically integrates with WebHare@webhare/std: Standard library APIs. Contains general APIs and APIs useful for integrating with WebHare, but designed to be usable without WebHare at all@webhare/jsonrpc-client: A generic JSON/RPC 1.0 Client.
Frontend libraries
@webhare/dompack: An updated version ofdompackwithout IE11 compatibility APIs and better aligned wth TypeScript@webhare/dompack-overlays: A utility package - used to be a separate project, now integrated@webhare/frontend: Various frontend utilities, replaces the old 'whintegration' libraries@webhare/forms: Publisher forms APIs
Backend libraries
@webhare/cli: Implements command line utilities (implements argument parsing, autocomplete, ANSI)@webhare/services: Accesses WebHare resources (modules, database)@webhare/system-tools: Utility APIs to build WebHare backend apps (but these APIs do not themselves depend on WebHare). This is basically a @webhare/std for nodejs.
HareScript and Compatibility
@webhare/harescript:loadliband other APIs to directly invoke HareScript using the WASM HareScript engine@webhare/hscompat: Standard APIs useful when converting or interfacing with HareScript code
Development
@webhare/eslint-config: ESLint rules used by WebHare@webhare/test: WebHare test framework, generic@webhare/test-backend: Backend (server) test framework@webhare/test-frontend: Frontend (browser) test framework
Working with NPM libraries/node_modules
WebHare exposes some APIs of the node_modules it ships with through its own modules (eg pg, kysely) but third-party modules should not directly include the node_modules
shipped with WebHare as they may be removed or receive incompatible upgrades without advance notice. Modules should stick to either the public APIs of @webhare/ modules
or install the necessary modules themselves.