vite_plugin_library_well_known #

vite_plugin_library_well_known publishes metadata to .well-known/ in your build output: package.json and library.json.

Requires a generated library.json file, as created by library_gen via gro gen.

Setup
#

1. Create src/routes/library.gen.ts:

import {library_gen} from '@fuzdev/fuz_ui/library_gen.js';

export const gen = library_gen();

2. Run gro gen to generate src/routes/library.json (or run the dev server, or build)

3. Add plugin to vite.config.ts:

import {defineConfig} from 'vite';
import {sveltekit} from '@sveltejs/kit/vite';
import {vite_plugin_library_well_known} from '@fuzdev/fuz_ui/vite_plugin_library_well_known.js';

export default defineConfig({
  plugins: [sveltekit(), vite_plugin_library_well_known()],
});

Output
#

The plugin emits two files to .well-known/:

/.well-known/package.json - package metadata only, much smaller than library.json for lightweight usage
/.well-known/library.json - full library metadata including package.json, modules, declarations, JSDoc, and type signatures

Options
#

By default, the plugin looks for ./src/routes/library.json. Customize with the library_path option:

vite_plugin_library_well_known({
  library_path: './src/lib/library.json',
})

Why `.well-known/`?
#

Writing to .well-known/package.json and .well-known/library.json extends Well-known URIs (RFC 8615) for JS packages to provide conventional metadata for deployed websites. A popular example is how Mastodon uses WebFinger, which uses .well-known/ for user identity discovery.

SvelteKit outputs static files relative to the configured base path, so the .well-known directory may not be in the root /. This enables websites to provide metadata even when hosted in a namespaced path like username.github.io/projectname/.well-known. This breaks from the RFC but hopefully not in the bad-citizen kind of way; the alternative would be to ignore the standard and do something bespoke, which seems worse.

Why publish this metadata to the web instead of relying on the git repo?

give all web users and tools access to discoverable package metadata
metadata is a much lighter dependency than an entire repo
some repos are deployed to multiple websites with metadata differences
some repos like monorepos have multiple package.json files
no dependency on git or the URL patterns of forge hosts like GitHub
the git repo remains the source of truth, the build step gives control over the published artifacts