Problem
The docs (and the natural user expectation) reference a drop-in script at https://unpkg.com/playhtml/init.js, but that file has never been published. The build emits dist/init.es.js (a 2-line module that imports playhtml and calls init({})), and the package files/exports only expose dist/. So the short URL 404s.
PR #220 worked around this by pointing the docs at the verbose https://unpkg.com/playhtml/dist/init.es.js. This issue is the proper fix: make the friendly short URL resolve.
Goal
https://unpkg.com/playhtml/init.js should load and run playhtml.init({}), so the Path A drop-in in getting-started.mdx can use the short, memorable URL.
Approach
unpkg resolves real files on disk in the published tarball (it does not consult bundler-style exports subpath maps for bare paths like /playhtml/init.js). So the fix needs an actual init.js file in the published package root, plus an exports entry for correctness when imported via a bundler.
Concretely:
- Emit (or add) a root-level
init.js in the published package that does the same thing as dist/init.es.js (import { playhtml } from "./dist/playhtml.es.js"; playhtml.init({});). Either change the vite build fileName to also output init.js at the publish root, or add a tiny committed init.js re-export and include it in package.json files.
- Add
"./init.js": "./init.js" (or ./dist/init.es.js) to the exports map.
- Add
init.js to package.json files if it's a committed file.
- Verify against a real unpkg URL after publish (the build hash path resolves) —
curl -sI https://unpkg.com/playhtml@<next-version>/init.js should 200.
Acceptance criteria
Context
Problem
The docs (and the natural user expectation) reference a drop-in script at
https://unpkg.com/playhtml/init.js, but that file has never been published. The build emitsdist/init.es.js(a 2-line module that importsplayhtmland callsinit({})), and the packagefiles/exportsonly exposedist/. So the short URL 404s.PR #220 worked around this by pointing the docs at the verbose
https://unpkg.com/playhtml/dist/init.es.js. This issue is the proper fix: make the friendly short URL resolve.Goal
https://unpkg.com/playhtml/init.jsshould load and runplayhtml.init({}), so the Path A drop-in ingetting-started.mdxcan use the short, memorable URL.Approach
unpkg resolves real files on disk in the published tarball (it does not consult bundler-style
exportssubpath maps for bare paths like/playhtml/init.js). So the fix needs an actualinit.jsfile in the published package root, plus anexportsentry for correctness when imported via a bundler.Concretely:
init.jsin the published package that does the same thing asdist/init.es.js(import { playhtml } from "./dist/playhtml.es.js"; playhtml.init({});). Either change the vite buildfileNameto also outputinit.jsat the publish root, or add a tiny committedinit.jsre-export and include it inpackage.jsonfiles."./init.js": "./init.js"(or./dist/init.es.js) to theexportsmap.init.jstopackage.jsonfilesif it's a committed file.curl -sI https://unpkg.com/playhtml@<next-version>/init.jsshould 200.Acceptance criteria
https://unpkg.com/playhtml/init.jsreturns the init module (200, not 404) after the next release.playhtmlpatch).apps/docs/src/content/docs/getting-started.mdxPath A back tohttps://unpkg.com/playhtml/init.js(and the two prose mentions).dist/init.es.jspath.Context
packages/playhtml/vite.config.ts(thefileNamefn emitsinit.${format}.jsfor theinitentry).packages/playhtml/package.jsonfiles/exports.