Getting Started

Install the patched release (tenseg/barnacle v0.2.1) and re-run any documented publish/install step for the package.
v0.2.1 fixes a typo that prevented new Barnacle cookie installation. If you are on v0.2.0 and rely on first-visit cookie creation, upgrade before debugging application code.
First use case: place the package where a new visitor/session should receive the Barnacle cookie, then verify the first response includes the expected Set-Cookie header and later requests reuse it.

Implementation Patterns

Treat Barnacle cookie creation as an explicit first-visit concern. Invoke it from the narrowest integration point: middleware, event listener, or controller action that knows a new cookie should be issued.
Keep cookie attributes such as name, domain, path, expiry, Secure, HttpOnly, and SameSite in configuration and vary them by environment rather than hard-coding them.
Test the flow with feature tests: assert the cookie is present on the first response, then simulate a follow-up request carrying that cookie and assert the package recognizes it.
On upgrade, verify both new cookie installation and existing-cookie behavior. The release notes indicate a targeted bug fix rather than a new feature or API change.

If new cookies still do not appear after v0.2.1, check config cache, route cache, response middleware order, and whether another middleware strips Set-Cookie.
Cookie domain/path mismatches, Secure cookies on non-HTTPS local development, and restrictive SameSite settings are common reasons a cookie is issued but not sent back.
Test “new installation” in an incognito window or after clearing Barnacle cookies; an existing cookie can mask first-visit bugs.
The v0.2.1 change is small but operationally important: upgrade from v0.2.0 if first-time cookie installation is part of your flow. No breaking changes or deprecations are indicated in the release notes.