pi-meta-oauth 0.2.2 → 0.3.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (4) hide show
  1. package/README.md +4 -2
  2. package/extensions/media.ts +1446 -0
  3. package/extensions/meta.ts +43 -8
  4. package/package.json +2 -1
package/README.md CHANGED
@@ -88,7 +88,7 @@ bun test
88
88
 
89
89
  ## Publish to npm and pi.dev
90
90
 
91
- The `pi-package` keyword makes the package discoverable at <https://pi.dev/packages>. Publishing is handled by `.github/workflows/publish.yml` when a `v*` tag is pushed.
91
+ The `pi-package` keyword makes the package discoverable at <https://pi.dev/packages>. Publishing is handled by `.github/workflows/publish.yml` when a `v*` tag is pushed. Each release publishes the canonical `pi-meta-oauth` package to npm and a scoped `@blockedpath/pi-meta-oauth` mirror to GitHub Packages.
92
92
 
93
93
  Before the first automated release, configure npm trusted publishing for `pi-meta-oauth` with:
94
94
 
@@ -98,7 +98,9 @@ Before the first automated release, configure npm trusted publishing for `pi-met
98
98
  - Environment: leave blank
99
99
  - Allowed action: `npm publish`
100
100
 
101
- Bump `package.json`, commit the change, create a `v<version>` tag, and push the commit and tag. The workflow verifies that the tag matches the package version, runs typechecking and tests, publishes to npm with provenance, and creates the GitHub Release. Re-running a partially completed workflow is safe when npm reports that the same commit was already published.
101
+ GitHub Packages uses the workflow's short-lived `GITHUB_TOKEN`. Its npm registry defaults new packages to private visibility; after the first publish, open the package settings on GitHub and change its visibility to **Public** if desired.
102
+
103
+ Bump `package.json`, commit the change, create a `v<version>` tag, and push the commit and tag. The workflow verifies that the tag matches the package version, runs typechecking and tests, publishes to both registries, and creates the GitHub Release. Re-running a partially completed workflow is safe when either registry reports that the same commit was already published.
102
104
 
103
105
  Users can then update with:
104
106