Plugin overview

This repository contains publishable TypeScript packages that encapsulate shared Investec Online platform business logic. The platform consumes the published packages. Consuming teams can contribute additional API calls, mappings, and configuration when the change fits an existing plugin's purpose.

The Web Platform team governs package boundaries and platform adoption. Contact the team before creating a plugin or making a substantial change to security, state lifecycle, shared architecture, or a published contract.

Workspace structure

• each plugin is a top-level Nx library;
• each publishable package has its own package.json, project.json, and .azure-pipelines.yml;
• src/index.ts defines the public contract;
• VitePress documentation lives in docs/;
• plugins-demo is the local harness for exercising plugin APIs.

Plugin packages

Package	Responsibility	Main exports	Consumer-installable?
@investec/plugins-adobe-analytics	Standardised Adobe Analytics event building and data-layer dispatch	AdobeAnalytics	No — platform-only
@investec/plugins-client-type-router	Route URL context to clientType and shell interaction state	routeClientTypeBasedOnUrl, DEFAULT_ROUTE_RULES	No — platform-only
@investec/plugins-cobrowse	Privacy-first Cobrowse.io lifecycle, session codes, cross-origin iframe bridging, and redaction	InvestecCobrowse, cobrowse	No — platform-only
@investec/plugins-experience-manager	Determine pre-login and post-login destinations	determineJourneyPreLogin, determineJourneyAfterLogin, decodeDestination	No — platform-only
@investec/plugins-feature-flags-builder	Legacy feature-flag aggregation from gateway endpoints	getUserFeaturesWeb	No — platform-only
@investec/plugins-feature-library	Feature-registry loading, favourites, eligibility, Adobe Target overrides, and search	getWebFeatures, checkFeatureRequirements, featureSearch, addFavouriteFeature	No — platform-only
@investec/plugins-left-nav-builder	Build left-nav items from menu state and client context	leftNavBuilder, getLoggedInMenuState	No — platform-only
@investec/plugins-livechat	NICE CXone chat wrapper with thread recovery and browser events	LiveChat	Yes — approved exception (see livechat.md)
@investec/plugins-menu-builder	Aggregate multiple menu APIs into one menu model	menuBuilder, setupMenu	No — platform-only
@investec/plugins-personalisation	Adobe Target content retrieval and profile-update helpers	getAdobeTargetDataByTemplate, postProfileUpdatesByTemplate	No — platform-only
@investec/plugins-portfolio-builder	Portfolio aggregation, totals, contact data, and portfolio streaming	portfolioBuilder, portfolio	No — platform-only
@investec/plugins-profiles-builder	Retrieve and normalise client profiles	profilesBuilder, getProfiles	No — platform-only
@investec/plugins-toggles-builder	Legacy toggle and feature-disable mapping	getToggles, mapToggles, removeToggledFeatures	No — platform-only

Integration model

The packages fall into four groups.

Stateful shell builders

• Menu builder
• Left nav builder
• Portfolio builder
• Profiles builder

These packages expose ReplaySubject-based state objects, expect environment and auth context to be injected first, and emit updates incrementally.

Shell routing and journey helpers

• Experience manager
• Client type router

These packages are pure or mostly pure decision layers that map URL or auth context to navigation outcomes and shell chrome state.

Discovery and personalisation

• Feature library
• Feature flags builder
• Toggles builder
• Personalisation

These packages decide what a customer can see, open, or be shown, often by combining feature-registry data with authenticated client context.

External integrations

• Adobe analytics
• Cobrowse
• Livechat

These packages wrap third-party systems behind a smaller platform-facing API.

Consumer expectations

Before using a plugin:

1. import from the package root, not from internal file paths;
2. set any exported activeEnvironment value before making calls;
3. inject required state such as authResponse, clientType, or menu data before triggering builder functions;
4. treat exported subjects and mutable module-level caches as application-lifetime state unless the package exposes an explicit reset path.

How consumers extend plugin behaviour

Use one of two extension paths.

For application-owned behaviour:

1. shaping the plugin input;
2. wrapping the emitted output in app-owned state;
3. composing application-specific rules after the plugin result;
4. using any explicit extension hook the package exposes.

For shared platform business logic, contribute to the existing plugin by adding the approved API helper, configuration entry, mapping, type, test, and documentation. Do not reproduce the same shared rule in multiple consumers.

Use Plugin change governance to decide whether an AI or contributor can make the change directly or must first obtain platform-team approval.

Legacy packages

feature-flags-builder and toggles-builder are legacy compatibility layers. They remain useful when the platform still expects their data shape, but they are not the preferred place to introduce new entitlement logic.

Related pages

• Get started
• Plugin change governance
• Extension patterns
• Plugin demo
• Plugin documentation knowledge source

For the standards contributors and agents must follow when expanding a shared plugin, start with Plugin change governance, Get started, and Extension patterns.