Storage overview

Every resource the mock manages is persisted through a storage backend. Repositories read and write through this abstraction, so swapping the backend doesn’t change API behaviour.

Available backends

Backend	Import	State	Use for
In-memory	InMemoryStorage	Per-process, volatile	The default — unit/integration tests.
SQLite (experimental)	SQLiteStorage (from /sqlite)	File or :memory:	Larger datasets, persistence across restarts of the standalone server.
Custom	extend AbstractStorage	Whatever you implement	Special persistence or inspection needs.

Choosing a backend

Set the storage option on the constructor. Leaving it unset uses InMemoryStorage:

import { CommercetoolsMock, InMemoryStorage } from '@labdigital/commercetools-mock'

// default (in-memory)
new CommercetoolsMock({ defaultProjectKey: 'my-project' })

// explicit in-memory
new CommercetoolsMock({ storage: new InMemoryStorage() })

import { CommercetoolsMock } from '@labdigital/commercetools-mock'
import { SQLiteStorage } from '@labdigital/commercetools-mock/sqlite'

new CommercetoolsMock({ storage: new SQLiteStorage({ filename: ':memory:' }) })

The contract

A backend extends AbstractStorage and implements async methods for adding, getting, querying, deleting and clearing resources. All methods return Promises. See Custom backends for the shape.