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).
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.
@webhare/dompack: An updated version of
dompackwithout 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
@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
loadliband other APIs to directly invoke HareScript using the WASM HareScript engine
@webhare/hscompat: Standard APIs useful when converting or interfacing with HareScript code
@webhare/eslint-config: ESLint rules used by WebHare
@webhare/test: WebHare tes tframework
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
shipped with WebHare as they may be removed or receive incompatible upgrades without advance notice. Modules should stick to either the public APIs of
or install the necessary modules themselves.