poveste 0.16.1 → 0.16.2

package/dist/node/vendors.d.ts

@@ -0,0 +1,74 @@
+/**
+ * Resolves `specifier` as Node would from `from`, to a real path, or `undefined`
+ * when nothing answers.
+ */
+export type Resolver = (specifier: string, from: string) => string | undefined;
+export declare const nodeResolver: Resolver;
+export interface VendoredAlias {
+    /** The bare package the alias points at, `vue`. */
+    name: string;
+    /** The range it is pinned to, `^3.5.26`, or `''` when the spec carries none. */
+    range: string;
+}
+/**
+ * What each vendored dependency aliases, by the name it is installed under:
+ * `{ 'poveste-vue': { name: 'vue', range: '^3.5.26' } }` from
+ * `"poveste-vue": "npm:vue@^3.5.26"`.
+ *
+ * Derived from the manifest rather than listed, because the set is whatever
+ * `@poveste/vendors` declares and a list here would keep working while silently
+ * covering one name fewer. The range comes back with the name because the caller
+ * needs both and this is the only place the spec is parsed.
+ */
+export declare function vendoredAliases(dependencies: Record<string, string> | undefined): Record<string, VendoredAlias>;
+/**
+ * Whether `version` satisfies a caret range, for the caret ranges `@poveste/vendors`
+ * actually declares and **nothing else**.
+ *
+ * A range this cannot read with certainty is refused rather than approximated. That
+ * is the point: `poveste` has no `semver` dependency, a patch release is the wrong
+ * place to add one, and a hand-rolled `satisfies` that silently mis-handles a form it
+ * was never given is the failure this repo keeps producing. So `^X.Y.Z` with a major
+ * of at least 1 is answered, and `^0.x`, a prerelease, a comparator set or anything
+ * else returns false and leaves the chrome on the copy it can certainly run.
+ */
+export declare function satisfiesCaret(version: string | undefined, range: string | undefined): boolean;
+/**
+ * Points the chrome's Vue at the project's, when they are two copies.
+ *
+ * `@poveste/vendors` depends on `poveste-vue`, an npm alias of `vue`. An alias is
+ * a **distinct package name**, so a package manager installs a second physical copy
+ * whatever the project already has — the project's Vue satisfying the aliased range
+ * does not collapse them, and `resolve.dedupe` cannot, because it matches on name.
+ *
+ * Two copies is two reactivity systems. The chrome's components render with the
+ * vendored one while `RouterView` — reached through `poveste-vue-router`, whose own
+ * `vue` import is bare — reacts with the project's, so `RouterView`'s first render
+ * is never invalidated and a Vue consumer's `poveste dev` showed a sidebar, a
+ * breadcrumb and no story at all. Nothing warns: neither copy is wrong, they simply
+ * cannot see each other (#1060).
+ *
+ * Only Vue. The reactivity identity is what breaks, and `@poveste/plugin-vue`
+ * declaring `vue` as a peer is what licenses pointing the chrome at the project's
+ * copy — no peer range licenses the same for pinia, vue-router, VueUse or Iconify,
+ * and making the chrome's pinned copies authoritative for a project's own story code
+ * is a larger change than this defect asks for.
+ *
+ * Empty when the project has no Vue of its own, when the two already resolve to one
+ * file, or when the project's Vue does not satisfy the range vendors pins — in each
+ * case the vendored copy is what the chrome should keep. Refusing on anything it
+ * cannot read with certainty is deliberate: the failure of this function is a chrome
+ * that keeps a Vue it can certainly run, and the failure of guessing is a chrome
+ * handed one it cannot.
+ *
+ * The range is checked rather than assumed from the peer floor. A project only holds
+ * a Vue of its own because a framework plugin's peer range put it there — except that
+ * `--legacy-peer-deps` is exactly how a project ends up holding one the peer range
+ * would have refused (#1062), which leaves a reader on, say, Vue 3.2 with a chrome
+ * collapsed onto a Vue that cannot run it. Such a project is already broken without
+ * this fix, but "already broken" is not a reason to hand it a different break.
+ */
+export declare function collapseVendoredVue(options: {
+    root: string;
+    resolve?: Resolver;
+}): Record<string, string>;

package/dist/node/vendors.js

@@ -0,0 +1,157 @@
+import { readFileSync, realpathSync } from 'node:fs';
+import { createRequire } from 'node:module';
+import { join } from 'pathe';
+export const nodeResolver = (specifier, from) => {
+    try {
+        // `createRequire` resolves relative to the *dirname* of what it is given, so a
+        // directory has to be named as a file inside it or every lookup starts one
+        // level too high.
+        return realpathSync(createRequire(join(from, 'noop.js')).resolve(specifier));
+    }
+    catch {
+        return undefined;
+    }
+};
+/**
+ * What each vendored dependency aliases, by the name it is installed under:
+ * `{ 'poveste-vue': { name: 'vue', range: '^3.5.26' } }` from
+ * `"poveste-vue": "npm:vue@^3.5.26"`.
+ *
+ * Derived from the manifest rather than listed, because the set is whatever
+ * `@poveste/vendors` declares and a list here would keep working while silently
+ * covering one name fewer. The range comes back with the name because the caller
+ * needs both and this is the only place the spec is parsed.
+ */
+export function vendoredAliases(dependencies) {
+    const aliases = {};
+    for (const [installedAs, spec] of Object.entries(dependencies ?? {})) {
+        if (!spec.startsWith('npm:')) {
+            continue;
+        }
+        // Split on the last `@` rather than matching a name pattern: a scoped package
+        // opens with one, so the separator is positional and a regex that allows both
+        // is the kind the linter rejects for backtracking.
+        const target = spec.slice('npm:'.length);
+        const at = target.lastIndexOf('@');
+        aliases[installedAs] = at > 0
+            ? { name: target.slice(0, at), range: target.slice(at + 1) }
+            : { name: target, range: '' };
+    }
+    return aliases;
+}
+/**
+ * Whether `version` satisfies a caret range, for the caret ranges `@poveste/vendors`
+ * actually declares and **nothing else**.
+ *
+ * A range this cannot read with certainty is refused rather than approximated. That
+ * is the point: `poveste` has no `semver` dependency, a patch release is the wrong
+ * place to add one, and a hand-rolled `satisfies` that silently mis-handles a form it
+ * was never given is the failure this repo keeps producing. So `^X.Y.Z` with a major
+ * of at least 1 is answered, and `^0.x`, a prerelease, a comparator set or anything
+ * else returns false and leaves the chrome on the copy it can certainly run.
+ */
+export function satisfiesCaret(version, range) {
+    const wanted = /^\^(\d+)\.(\d+)\.(\d+)$/.exec(range ?? '');
+    const have = /^(\d+)\.(\d+)\.(\d+)$/.exec(version ?? '');
+    if (!wanted || !have) {
+        return false;
+    }
+    const [wantedMajor, wantedMinor, wantedPatch] = wanted.slice(1).map(Number);
+    const [major, minor, patch] = have.slice(1).map(Number);
+    // `^0.x` narrows to the minor, and no vendored range uses it. Refuse rather than
+    // implement a rule nothing here exercises.
+    if (wantedMajor === 0 || wantedMajor === undefined || major === undefined) {
+        return false;
+    }
+    if (major !== wantedMajor) {
+        return false;
+    }
+    if (minor !== wantedMinor) {
+        return minor > wantedMinor;
+    }
+    return patch >= wantedPatch;
+}
+/**
+ * Points the chrome's Vue at the project's, when they are two copies.
+ *
+ * `@poveste/vendors` depends on `poveste-vue`, an npm alias of `vue`. An alias is
+ * a **distinct package name**, so a package manager installs a second physical copy
+ * whatever the project already has — the project's Vue satisfying the aliased range
+ * does not collapse them, and `resolve.dedupe` cannot, because it matches on name.
+ *
+ * Two copies is two reactivity systems. The chrome's components render with the
+ * vendored one while `RouterView` — reached through `poveste-vue-router`, whose own
+ * `vue` import is bare — reacts with the project's, so `RouterView`'s first render
+ * is never invalidated and a Vue consumer's `poveste dev` showed a sidebar, a
+ * breadcrumb and no story at all. Nothing warns: neither copy is wrong, they simply
+ * cannot see each other (#1060).
+ *
+ * Only Vue. The reactivity identity is what breaks, and `@poveste/plugin-vue`
+ * declaring `vue` as a peer is what licenses pointing the chrome at the project's
+ * copy — no peer range licenses the same for pinia, vue-router, VueUse or Iconify,
+ * and making the chrome's pinned copies authoritative for a project's own story code
+ * is a larger change than this defect asks for.
+ *
+ * Empty when the project has no Vue of its own, when the two already resolve to one
+ * file, or when the project's Vue does not satisfy the range vendors pins — in each
+ * case the vendored copy is what the chrome should keep. Refusing on anything it
+ * cannot read with certainty is deliberate: the failure of this function is a chrome
+ * that keeps a Vue it can certainly run, and the failure of guessing is a chrome
+ * handed one it cannot.
+ *
+ * The range is checked rather than assumed from the peer floor. A project only holds
+ * a Vue of its own because a framework plugin's peer range put it there — except that
+ * `--legacy-peer-deps` is exactly how a project ends up holding one the peer range
+ * would have refused (#1062), which leaves a reader on, say, Vue 3.2 with a chrome
+ * collapsed onto a Vue that cannot run it. Such a project is already broken without
+ * this fix, but "already broken" is not a reason to hand it a different break.
+ */
+export function collapseVendoredVue(options) {
+    const { root } = options;
+    const resolve = options.resolve ?? nodeResolver;
+    // From the vendors directory, not from the project: that is where the import
+    // happens, and an isolated `node_modules` layout makes `poveste-vue` invisible
+    // from the project root while the chrome resolves it perfectly well.
+    // Through an exported subpath: vendors' `exports` map does not list
+    // `./package.json`, so resolving that name directly fails.
+    const vendorsEntry = resolve('@poveste/vendors/vue', root);
+    const vendorsDir = vendorsEntry ? join(vendorsEntry, '..') : undefined;
+    if (!vendorsDir) {
+        return {};
+    }
+    const vueAlias = Object.entries(vendoredAliases(readJson(join(vendorsDir, 'package.json'))?.dependencies))
+        .find(([, alias]) => alias.name === 'vue');
+    if (!vueAlias) {
+        return {};
+    }
+    const [installedAs, { range }] = vueAlias;
+    const vendored = resolve(installedAs, vendorsDir);
+    const project = resolve('vue', root);
+    if (!vendored || !project || vendored === project) {
+        return {};
+    }
+    if (!satisfiesCaret(versionOf('vue/package.json', resolve, root), range)) {
+        return {};
+    }
+    // To the bare name, not to `project`. A resolved path is whatever the `require`
+    // condition answers — for Vue that is a CJS shim, and handing the chrome that
+    // replaced a split reactivity system with a browser app that does not boot at all.
+    // The name lets Vite resolve its own entry and condition, and `resolve.dedupe`
+    // above then genuinely covers the result.
+    return { [installedAs]: 'vue' };
+}
+function versionOf(specifier, resolve, root) {
+    const manifest = resolve(specifier, root);
+    if (!manifest) {
+        return undefined;
+    }
+    return readJson(manifest)?.version;
+}
+function readJson(file) {
+    try {
+        return JSON.parse(readFileSync(file, 'utf8'));
+    }
+    catch {
+        return undefined;
+    }
+}

package/dist/node/vite.js

@@ -11,6 +11,7 @@ import { notifyStoryChange } from './stories.js';
 import { chromeCssScopePlugin, globalStylesPlugin, userCssScopePlugin, } from './style-isolation/index.js';
 import { applyHeadTransform } from './util/head.js';
 import { viteCommand, viteMode } from './util/vite-mode.js';
+import { collapseVendoredVue } from './vendors.js';
 import { createVirtualFilesPlugin } from './virtual/vite-plugin.js';
 const require = createRequire(import.meta.url);
 export async function mergePovesteViteConfig(viteConfig, ctx) {
@@ -153,6 +154,14 @@ export async function getViteConfigWithPlugins(isServer, ctx) {
                     ],
                     alias: {
                         'poveste-style': join(APP_PATH, process.env['POVESTE_DEV'] ? 'app/style/main.pcss' : 'style.css'),
+                        // `dedupe` above cannot reach this one: the chrome's Vue is installed
+                        // under a different name, and dedupe matches on the name (#1060).
+                        //
+                        // Not under `POVESTE_DEV`. That path already aliases bare `vue` to
+                        // `@poveste/vendors/vue`, so sending `poveste-vue` back to `vue` would
+                        // point the vendored entry at itself — the empty re-export its own
+                        // comment warns about.
+                        ...(isServer || process.env['POVESTE_DEV'] ? {} : collapseVendoredVue({ root: ctx.root })),
                     },
                     ...(isServer
                         ? {

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "poveste",
   "type": "module",
-  "version": "0.16.1",
+  "version": "0.16.2",
   "description": "Interactive component playgrounds for Vue, Nuxt, Svelte, SvelteKit and Quasar — a drop-in fork of histoire, with Quasar support histoire does not ship.",
   "author": {
     "name": "Sorin Gitlan",
@@ -74,10 +74,10 @@
   },
   "dependencies": {
     "@11ty/gray-matter": "^3.0.0",
-    "@poveste/app": "^0.16.1",
-    "@poveste/controls": "^0.16.1",
-    "@poveste/shared": "^0.16.1",
-    "@poveste/vendors": "^0.16.1",
+    "@poveste/app": "^0.16.2",
+    "@poveste/controls": "^0.16.2",
+    "@poveste/shared": "^0.16.2",
+    "@poveste/vendors": "^0.16.2",
     "change-case": "^5.4.4",
     "chokidar": "^5.0.0",
     "defu": "^6.1.4",