Greg Jacobs fragginwagon
  • London, Ontario, Canada
  • Joined on 2026-01-26

@fraggin/document-browser-kit (0.1.6)

Published 2026-05-06 17:40:09 -04:00 by fragginwagon

Installation

@fraggin:registry=
npm install @fraggin/document-browser-kit@0.1.6
"@fraggin/document-browser-kit": "0.1.6"

About this package

@fraggin/document-browser-kit

Shared document-browser primitives used by the Pokemon rules browser and Datasift.

Package purpose

This repository owns product-neutral document-browser code:

  • generic search and browser state helpers
  • reusable Vue document-browser components and composables
  • shared build-time indexing utilities
  • shared base styles that are not product-branded

Pokemon-specific and Datasift-specific branding, content grouping, and app orchestration stay in their consumer repositories.

Validate and publish

The package publish workflow lives in .gitea/workflows/publish.yaml.

  1. Make the shared change here.
  2. Run the package validation locally:
    npm run validate:ci
    
  3. Bump package.json to the next version.
  4. Commit the change and push it.
  5. Push a matching vX.Y.Z git tag. The publish workflow only runs on v* tags.
  6. Wait for the validation job and publish job to finish successfully.
  7. Wait for the new package version to appear in the Gitea npm registry. There can be a short propagation delay after the tag is pushed.

Publishing is version-tag driven. A commit on its own does not publish a package.

Consumer update flow

After a shared slice is published:

  1. Update pokemon-rules-browser with an explicit install:
    npm install @fraggin/document-browser-kit@<version>
    
  2. Update ~/Developer/Source Code/boilerplates/datasift/ the same way.
  3. Run both consumer builds before treating the shared slice as complete.

Prefer an explicit versioned install over a plain npm install when moving consumers to a new release. That refreshes package-lock.json cleanly and avoids leaving a stale file-based or older registry resolution in place.

Release contract for extracted slices

When a reusable slice is first built in a consumer repo such as Pokemon:

  1. Verify the behavior in the consumer.
  2. Extract the smallest generic slice into this package.
  3. Publish this package with a version bump and matching v<version> tag.
  4. Wait for registry availability.
  5. Move each consumer to the published version.
  6. Re-run consumer builds.

That sequence keeps this package as the source of truth and avoids consumers depending on unpublished shared changes.

Dependencies

Dependencies

ID Version
jsdom ^26.1.0
jszip ^3.10.1
mammoth ^1.10.0
pdfjs-dist ^4.10.38

Peer Dependencies

ID Version
vue ^3.5.13
Details
npm
2026-05-06 17:40:09 -04:00
1
latest
24 KiB
Assets (1)
Versions (6) View all
0.1.6 2026-05-06
0.1.5 2026-05-06
0.1.4 2026-05-05
0.1.3 2026-05-04
0.1.2 2026-05-04