Snippets

Snippets are reusable JavaScript blocks stored app-wide under Settings → Snippets. Instead of copying the same code into many requests, add a snippet reference to a script list with Select snippet....

A snippet reference is a live pointer, not a copy of the code. When you edit a snippet in Settings, every script list that references it runs the updated code on the next send. If you delete a snippet, requests that referenced it show Missing snippet in the editor and skip that entry at send time.

Snippets are stored locally on your machine (in the app's local database). They are not embedded in collection or request export files. After importing a collection on another machine, recreate any needed snippets locally, import portable snippet JSON via File → Import, or replace snippet references with inline scripts. Git-backed storage locations also write snippet exports under snippets/ in the repository. See Settings — Snippets and Using snippets for managing the snippet library.

Importing snippets

You can also reuse snippet code with standard JavaScript import syntax inside inline scripts (and inside other snippets). This complements Select snippet… — use a script-list reference when the snippet should run as its own stage slot; use import when you want shared helpers without an extra list entry.

Importable names — only scripts or snippets whose display Name looks like a filename ending in .js can be imported. Examples: pass-testing.js, utils/format-date.js, or an inline script row named before.js. Human-readable names such as Pass Testing still work with Select snippet…, but cannot be import targets. Path segments may use letters, digits, dots, underscores, and hyphens; names must not start with / or contain ...

Import targets come from your snippet library and from inline scripts in the same request and its collection (pre- and post-request lists). A disabled inline script with an importable name remains importable as a helper-only module even when it does not run as its own slot.

Snippets export with ordinary ESM syntax (export function, export const, export default). A snippet can export helpers and include top-level code that runs when the snippet is used as a direct script slot.

Script editors autocomplete relative import paths after ./ — for example ./utils/ suggests folder segments and ./pass-testing.js suggests matching snippet files. When a snippet name is import-valid, Settings → Snippets shows a hint that other scripts may import it by filename; renaming may break existing imports.

At send time, HarborClient bundles relative ./…js imports against your snippet library and sibling inline scripts, then runs the result in the same SES sandbox as other scripts. Imported module top-level side effects run once per bundled script execution; module state does not persist across sends (use hc.data for structured data shared within one send).

Example — helper snippet (pass-testing.js in Settings → Snippets):

export function passTest(value) {
  hc.test("value is truthy", () => {
    hc.expect(value).to.be.true;
  });
}

Example — consuming inline script (imports a library snippet or a sibling inline script such as before.js):

import { before } from "./before.js";

before();

Nested paths work the same way: a snippet named utils/format-date.js is imported with import { formatDate } from "./utils/format-date.js".

Not supported yet: bare package imports such as import lodash from "lodash". npm packages and require are planned for a later release. Duplicate importable names (library snippets or inline scripts) produce an ambiguous-import error at send time.