npm - create-forte-ui - Versions diffs - 1.0.0-alpha.8 → 1.0.0-beta.0 - Mend

create-forte-ui 1.0.0-alpha.8 → 1.0.0-beta.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 (5) hide show

package/dist/overlay.js CHANGED Viewed

@@ -40,9 +40,14 @@ function applyVite({ name, dir, tailwind, answers }) {
      * report it, never guess. */
     const htmlPath = path.join(dir, "index.html");
     let html = fs.readFileSync(htmlPath, "utf8");
-    const attrs = htmlAttrs(answers);
+    /* `forte-reset` is unconditional — it switches on the reset stylesheet
+     * index.css imports, so the two must not drift. That makes the anchor
+     * always load-bearing here, unlike the theme attributes, which are empty on
+     * an all-defaults run: the guard below therefore checks the replacement
+     * outright rather than only when `attrs` is non-empty. */
+    const attrs = `${htmlAttrs(answers)} class="forte-reset"`;
     const anchored = html.replace(/<html lang="en">/, `<html lang="en"${attrs}>`);
-    if (attrs && anchored === html) {
+    if (anchored === html) {
         throw new Error(`could not find '<html lang="en">' in index.html to add${attrs} — ` +
             `the create-vite template may have changed; add the attribute(s) by hand.`);
     }

package/dist/templates.js CHANGED Viewed

@@ -4,7 +4,7 @@
  * diff a scaffolded app against the walkthrough and see only their own
  * answers. When a guide step changes, change the builder with it.
  */
-import { rootBlock, fontImports, htmlAttrs, nextFontSetup } from "./theme.js";
+import { rootBlock, fontImports, htmlAttrs, htmlClassAttr, nextFontSetup, } from "./theme.js";
 /* The body rule from the guides' "Replace the scaffold CSS" step. Present on
  * the non-Tailwind paths only — the Tailwind starter page carries the same
  * three declarations as utilities on `<main>`. */
@@ -56,6 +56,7 @@ export function viteIndexCss(a, tailwind) {
         return joinBlocks(fontBlock, `@import "@forte-ui/react/tailwind.css";
 @import "tailwindcss";
 @import "@forte-ui/react/theme.css";
+@import "@forte-ui/react/styles/reset.css";
 `, rootBlock(a, "import"));
     }
     return joinBlocks(fontBlock, rootBlock(a, "import"), BODY_RULE);
@@ -65,7 +66,9 @@ export function viteMainTsx(tailwind) {
      * bridge — importing it here would pin the `forte` layer first and hand
      * Preflight the win. Without Tailwind there is no ordering hazard and the
      * guide imports it at the entry point. */
-    const themeImport = tailwind ? "" : `import "@forte-ui/react/theme.css";\n`;
+    const themeImport = tailwind
+        ? ""
+        : `import "@forte-ui/react/theme.css";\nimport "@forte-ui/react/styles/reset.css";\n`;
     return `import { StrictMode } from "react";
 import { createRoot } from "react-dom/client";
 ${themeImport}import "./index.css";
@@ -130,6 +133,7 @@ export function nextGlobalsCss(a, tailwind) {
         return joinBlocks(`@import "@forte-ui/react/tailwind.css";
 @import "tailwindcss";
 @import "@forte-ui/react/theme.css";
+@import "@forte-ui/react/styles/reset.css";
 `, rootBlock(a, "next-font"));
     }
     return joinBlocks(rootBlock(a, "next-font"), BODY_RULE);
@@ -140,7 +144,9 @@ export function nextLayoutTsx(name, a, tailwind) {
      * because nothing else declares layers. With Tailwind it must NOT be:
      * globals.css imports it after the bridge (see the guide's ordering note),
      * and a second import here would pin the `forte` layer before `base`. */
-    const themeImport = tailwind ? "" : `import "@forte-ui/react/theme.css";\n`;
+    const themeImport = tailwind
+        ? ""
+        : `import "@forte-ui/react/theme.css";\nimport "@forte-ui/react/styles/reset.css";\n`;
     /* ThemeScript + suppressHydrationWarning are the guides' "Light and dark"
      * step: the script replays a stored light/dark choice onto <html> before
      * first paint, and the suppression covers the attribute it legitimately
@@ -175,7 +181,7 @@ export default function RootLayout({
   children: React.ReactNode;
 }>) {
   return (
-    <html lang="en"${htmlAttrs(a)}${font.htmlClassAttr}${pinned ? "" : " suppressHydrationWarning"}>
+    <html lang="en"${htmlAttrs(a)}${htmlClassAttr(font.fontVars)}${pinned ? "" : " suppressHydrationWarning"}>
 ${head}      <body>
 ${toggleLine}        {children}
       </body>

package/dist/theme.d.ts CHANGED Viewed

@@ -46,6 +46,19 @@ export type NextFontSetup = {
     /** The `const fontSans = Inter({...});` declarations, or "". */
     consts: string;
     /** ` className={...}` for the `<html>` element, or "". */
-    htmlClassAttr: string;
+    /** The `next/font` CSS-variable idents, e.g. ["fontSans.variable"]. The
+     *  `<html>` class list is composed from these plus `forte-reset`, which is
+     *  why this is the parts rather than a finished attribute. */
+    fontVars: string[];
 };
 export declare function nextFontSetup(a: ThemeAnswers): NextFontSetup;
+/** ` className="forte-reset"` — or a template literal when next/font variables
+ *  have to ride along on the same element.
+ *
+ *  `forte-reset` is unconditional: it is what switches on
+ *  `@forte-ui/react/styles/reset.css`, which the starter imports. A scaffolded
+ *  app is the one place the blanket reset is unambiguously right — there is no
+ *  existing markup for it to change behaviour under, and it becomes the
+ *  baseline everything the author writes next is built against. The library
+ *  itself stays scoped to `[data-forte]` for exactly the opposite reason. */
+export declare function htmlClassAttr(fontVars: string[]): string;

package/dist/theme.js CHANGED Viewed

@@ -113,7 +113,7 @@ export function nextFontSetup(a) {
         { font: findFont(MONO_FONTS, a.fontMono), variable: "--font-mono", ident: "fontMono" },
     ].filter((p) => p.font.css);
     if (picks.length === 0)
-        return { importLine: "", consts: "", htmlClassAttr: "" };
+        return { importLine: "", consts: "", fontVars: [] };
     const names = picks.map((p) => p.font.name.replaceAll(" ", "_"));
     const consts = picks
         .map((p, i) => {
@@ -122,12 +122,24 @@ export function nextFontSetup(a) {
         return `const ${p.ident} = ${names[i]}({ subsets: ["latin"], variable: "${p.variable}"${weightOpt} });`;
     })
         .join("\n");
-    const classExpr = picks.length === 1
-        ? `{${picks[0].ident}.variable}`
-        : `{\`\${fontSans.variable} \${fontMono.variable}\`}`;
     return {
         importLine: `import { ${names.join(", ")} } from "next/font/google";`,
         consts,
-        htmlClassAttr: ` className=${classExpr}`,
+        fontVars: picks.map((p) => `${p.ident}.variable`),
     };
 }
+/** ` className="forte-reset"` — or a template literal when next/font variables
+ *  have to ride along on the same element.
+ *
+ *  `forte-reset` is unconditional: it is what switches on
+ *  `@forte-ui/react/styles/reset.css`, which the starter imports. A scaffolded
+ *  app is the one place the blanket reset is unambiguously right — there is no
+ *  existing markup for it to change behaviour under, and it becomes the
+ *  baseline everything the author writes next is built against. The library
+ *  itself stays scoped to `[data-forte]` for exactly the opposite reason. */
+export function htmlClassAttr(fontVars) {
+    if (fontVars.length === 0)
+        return ` className="forte-reset"`;
+    const vars = fontVars.map((v) => `\${${v}}`).join(" ");
+    return ` className={\`forte-reset ${vars}\`}`;
+}

package/package.json CHANGED Viewed

@@ -1,6 +1,6 @@
 {
   "name": "create-forte-ui",
-  "version": "1.0.0-alpha.8",
+  "version": "1.0.0-beta.0",
   "description": "Scaffold a new app wired up with forte-ui — Vite or Next.js, with or without Tailwind, themed from your answers.",
   "license": "MIT",
   "type": "module",