From 368f5d3bfd40de4d8d08f05d7193dc9e4a9cad38 Mon Sep 17 00:00:00 2001 From: cproudlock Date: Mon, 3 Aug 2026 01:55:21 -0400 Subject: [PATCH] build(site): also stage a subpath frontend build Vite compiles the mount path into the bundle, so it cannot be chosen at install time from a single build - a page served under /shopdb would load and then request its assets from /assets/, and render nothing. build-site.sh now produces both: frontend-dist base / - the app on its own IIS site frontend-dist-subpath base / - an IIS Application under an existing site, e.g. http:///shopdb/ SUBPATH_ALIAS (default 'shopdb') is fixed per bundle and written into the staged build as .alias, so the three places that must agree - the IIS application alias, MOUNT_PATH in .env, and this compiled base - cannot drift apart. The installer checks that marker and refuses rather than serving a page that cannot load. The subpath build runs FIRST and is held in a temp dir: the root build has to be last so frontend/dist is left in the state a developer expects, and the copy into $OUT has to happen after the staging step that does rm -rf "$OUT". Co-Authored-By: Claude Opus 5 (1M context) --- scripts/build-site.sh | 22 ++++++++++++++++++++-- 1 file changed, 20 insertions(+), 2 deletions(-) diff --git a/scripts/build-site.sh b/scripts/build-site.sh index b6d29b3..f40b7ba 100755 --- a/scripts/build-site.sh +++ b/scripts/build-site.sh @@ -49,8 +49,24 @@ PY echo "Site profile: $PROFILE" echo "Plugin closure: $CLOSURE" -# Frontend: build carrying only the closure's plugins. -echo "==> Building frontend (SITE_PLUGINS=$CLOSURE) ..." +# Frontend: TWO builds, because Vite compiles the mount path into the bundle and +# it therefore cannot be chosen at install time from a single build - the page +# would load and then request its assets from the wrong path. +# dist -> own IIS site (method A, the default) +# dist-subpath -> IIS Application under an existing site (method B) +# SUBPATH_ALIAS is fixed per bundle so the three places that must agree - the IIS +# application alias, MOUNT_PATH and this base - cannot drift apart. +SUBPATH_ALIAS="${SUBPATH_ALIAS:-shopdb}" +SUBPATH_TMP="$(mktemp -d)" +trap 'rm -rf "$SUBPATH_TMP"' EXIT + +echo "==> Building frontend for /$SUBPATH_ALIAS/ (SITE_PLUGINS=$CLOSURE) ..." +( cd "$REPO/frontend" && SITE_PLUGINS="$CLOSURE" VITE_BASE_PATH="/$SUBPATH_ALIAS/" npm run build --silent ) +cp -r "$REPO/frontend/dist" "$SUBPATH_TMP/dist-subpath" +echo "$SUBPATH_ALIAS" > "$SUBPATH_TMP/dist-subpath/.alias" + +# Root build LAST, so frontend/dist is left in the state a developer expects. +echo "==> Building frontend for / (SITE_PLUGINS=$CLOSURE) ..." ( cd "$REPO/frontend" && SITE_PLUGINS="$CLOSURE" npm run build --silent ) # Backend: stage core + only the chosen plugin dirs. @@ -64,6 +80,8 @@ for name in ${CLOSURE//,/ }; do cp -a "$REPO/plugins/$name" "$OUT/plugins/" done cp -r "$REPO/frontend/dist" "$OUT/frontend-dist" +# Staged after the rm -rf above, or it would be deleted with everything else. +cp -r "$SUBPATH_TMP/dist-subpath" "$OUT/frontend-dist-subpath" # Runtime files a deployable tree needs beyond the Python packages. Without these # the staged tree can be imported but not actually run or migrated, so the