Bear Sync Laravel Package

Product Decisions This Supports

• A cheap go/no-go gate on “Bear as a content source.” The package proves the read path from Bear’s local SQLite store into Eloquent models for notes, tags, and metadata. For a PM, that turns a speculative roadmap question into a one-day spike: is Bear viable as an authoring source for a Laravel-backed site, newsletter, internal knowledge base, or publishing pipeline? The likely decision is “spike, don’t adopt.”
• Build vs. buy, resolved as “build, using this as a blueprint.” With 108 stars, zero dependents, an archived repository, and no release since February 2020, there is no vendor, support contract, or compatibility guarantee to buy. The useful deliverable is a small reference implementation showing how Bear’s private schema can be read at all. Adopt the pattern; fork or vendor the code; avoid making it a production Composer dependency.
• Scoping the addressable audience before design work. Bear is macOS-local, file-system-bound, and has no cloud API or webhook. That caps anything built on it to internal tools, single-author products, personal knowledge bases, and note-migration workflows. A PM should put that ceiling on the table in week zero. This package makes the constraint concrete and demonstrable instead of theoretical.
• Framing ingestion as an edge, not a platform. The package only reads. Downstream storage, search, publishing, permissions, and presentation remain application-owned. That architecture decision is reusable even if the code is discarded: copy Bear’s database, normalize into your own tables, wrap access behind an app-owned BearReader, and keep the ingestion layer replaceable.
• Running an honest bake-off against alternatives. A working Bear reader lets you compare Bear against Obsidian Markdown-on-disk, Notion’s official API, or a headless CMS with evidence rather than opinion. Bear is likely to lose on longevity, portability, and cross-platform grounds, but the PM can now say that with a spike result and a risk list.
• Resourcing the operational ownership question. Schema drift, silent zero-row imports, encrypted notes, missing attachments, and iCloud-incomplete databases are real failure modes. A PM decision here is not only “build it?” but “who owns revalidation on each Bear major release, and who gets paged when the sync imports nothing?” If no owner exists, do not greenlight production use.

When to Consider This Package

Consider it when:

• Your authors already work in Bear on macOS and your application runtime is Laravel/PHP.
• The consumer is internal, single-tenant, or yourself — not a paying customer with an SLA.
• You are running a time-boxed spike with a clear intent to fork or vendor the code and own it outright, rather than adding calebporzio/bear-sync to composer.json on a maintained stack.
• You need a readable reference for Bear schema access before commissioning your own reader; the evaluation value alone can justify a day of engineering.
• You are on an era-matching stack — roughly Laravel 6/7 and PHP 7.2–7.4 — and accept that direct installation is a short-term experiment, not a durable dependency.
• You can copy Bear’s SQLite database before every sync and treat the import as a batch job with schema guards and row-count alerts.

Look elsewhere when:

• Anything production or customer-facing. The repo is archived, unmaintained since the Laravel 7 era, has no security patching, no compatibility guarantees, no support channel, and effectively no community.
• You need a stable integration contract. Bear’s x-callback-url automation or exporting to Markdown and parsing files on disk is a materially more durable interface than an undocumented local database the vendor can change without notice.
• You need cross-platform or server-side ingestion. Bear’s database is a local Mac artifact. Linux or serverless topologies require a separate Mac-side sync agent you would have to build and operate — itself a product decision because it caps the addressable audience.
• Your team is not Laravel-native. The entire value is Eloquent ergonomics. Without Laravel, a small SQLite reader in any language is equivalent and carries less baggage.
• You need durability, support, security review, or long-term roadmap confidence. This package is a reference implementation, not a platform bet.
• You need encrypted-note handling or reliable full-text search from Bear’s internal tables. Encrypted notes arrive as opaque ciphertext, and Bear’s FTS tables are undocumented and rebuilt by Bear. Plan to skip or flag encrypted notes and re-index note bodies into your own search store.

How to Pitch It (Stakeholders)

For executives: This is a low-cost feasibility spike, not a platform commitment. In roughly one engineer-day, we can prove whether Bear notes can be ingested into a Laravel application and produce a go/no-go recommendation, a risk register, and a reference implementation. The package itself is archived, has no dependents, and has not shipped since 2020, so it should not enter production as a dependency. The strategic value is decision velocity: confirm the read path, expose the macOS-local audience ceiling, and compare Bear against more durable content sources before committing roadmap capacity. If the spike is greenlit for production, budget a small fork/vendor effort with named ownership for schema drift and sync monitoring — or choose Markdown export / x-callback-url as the safer interface.

For engineering: Treat this as a reference implementation and an ingestion edge. Read the source first; lift the schema-mapping queries into an app-owned BearReader class rather than installing the archived package on Laravel 10/11. Copy Bear’s SQLite database before every sync, add a schema guard using sqlite_master, and alert when row counts drop to zero or swing more than ~30%. Handle multiple images per note, missing attachments, encrypted notes, and tag hierarchy explicitly. Render Markdown at ingest, not read time; index note bodies into your own search store; keep Bear tables raw and normalize into downstream posts/articles tables. Expose only notes(), tags(), and attachments() behind an interface, schedule the sync with withoutOverlapping, and namespace any forked migrations. The realistic extension points are config path, service-provider binding, and repository wrapping; anything deeper means a fork, and since the repo is archived, plan for that fork to be a one-way door.