@mohasinac/appkit 4.74.0 → 4.76.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.
package/dist/.build-stamp.json
CHANGED
|
@@ -1,8 +1,8 @@
|
|
|
1
1
|
{
|
|
2
2
|
"stampVersion": 1,
|
|
3
|
-
"version": "4.
|
|
4
|
-
"head": "
|
|
3
|
+
"version": "4.76.0",
|
|
4
|
+
"head": "5da3ede2a94c94baadd8314d99ff43092dc5abd2",
|
|
5
5
|
"branch": "main",
|
|
6
6
|
"dirty": true,
|
|
7
|
-
"builtAt": "2026-11-
|
|
7
|
+
"builtAt": "2026-11-09T10:25:07.042Z"
|
|
8
8
|
}
|
|
@@ -58,5 +58,37 @@ export interface SitemapOptions {
|
|
|
58
58
|
* below exists to catch.
|
|
59
59
|
*/
|
|
60
60
|
excludeSections?: readonly SitemapSection[];
|
|
61
|
+
/**
|
|
62
|
+
* Skip the SHOP's surface-visibility policy — for a host that OWNS the
|
|
63
|
+
* sections it is emitting.
|
|
64
|
+
*
|
|
65
|
+
* ## 🛑 Why this is necessary and not a loophole
|
|
66
|
+
*
|
|
67
|
+
* `keep()` below withholds any URL under a closed browse section, an
|
|
68
|
+
* unlisted listing-type route, or a `closedSurfacePrefix` derived from
|
|
69
|
+
* `siteSettings.disabledRoutes`. That is exactly right for the shop: a
|
|
70
|
+
* surface it has switched off must not be advertised.
|
|
71
|
+
*
|
|
72
|
+
* It is exactly WRONG for an extracted subdomain, and the reason is almost
|
|
73
|
+
* funny: the shop disables `/blog` **because the blog moved to
|
|
74
|
+
* `blogs.<domain>`**. The subdomain then reads the same settings document,
|
|
75
|
+
* sees `/blog` disabled, and withholds its own content.
|
|
76
|
+
*
|
|
77
|
+
* Measured on 2026-11-09, from the blogs build log:
|
|
78
|
+
*
|
|
79
|
+
* sitemap: built {"sections":{"blog":16},"total":0}
|
|
80
|
+
*
|
|
81
|
+
* Sixteen posts fetched, every one filtered out, and a valid empty
|
|
82
|
+
* `<urlset>` served with HTTP 200. The pages themselves rendered perfectly
|
|
83
|
+
* throughout — only the sitemap was gone.
|
|
84
|
+
*
|
|
85
|
+
* 🛑 It does NOT skip the section scope. `sections`/`excludeSections` still
|
|
86
|
+
* apply, so this cannot be used to make one host emit another's URLs. It
|
|
87
|
+
* only stops the SHOP's visibility flags from governing a host the shop does
|
|
88
|
+
* not serve.
|
|
89
|
+
*
|
|
90
|
+
* 🛑 Leave it UNSET on the shop. There, those flags are the whole point.
|
|
91
|
+
*/
|
|
92
|
+
ownsSections?: boolean;
|
|
61
93
|
}
|
|
62
|
-
export declare function buildSitemap({ baseUrl, sections: only, excludeSections, }: SitemapOptions): Promise<MetadataRoute.Sitemap>;
|
|
94
|
+
export declare function buildSitemap({ baseUrl, sections: only, excludeSections, ownsSections, }: SitemapOptions): Promise<MetadataRoute.Sitemap>;
|
|
@@ -536,7 +536,7 @@ async function fetchScammerUrls(baseUrl) {
|
|
|
536
536
|
return sitemapSectionFailed("scammer", err);
|
|
537
537
|
}
|
|
538
538
|
}
|
|
539
|
-
export async function buildSitemap({ baseUrl, sections: only, excludeSections, }) {
|
|
539
|
+
export async function buildSitemap({ baseUrl, sections: only, excludeSections, ownsSections = false, }) {
|
|
540
540
|
/*
|
|
541
541
|
* Which sections this host emits. See `SitemapOptions.sections` for why a
|
|
542
542
|
* host must be able to answer this at all.
|
|
@@ -697,6 +697,12 @@ export async function buildSitemap({ baseUrl, sections: only, excludeSections, }
|
|
|
697
697
|
*/
|
|
698
698
|
const closedPrefixes = closedSurfacePrefixes(settings);
|
|
699
699
|
const keep = (entry) => {
|
|
700
|
+
/*
|
|
701
|
+
* A host that OWNS its sections is not governed by the shop's visibility
|
|
702
|
+
* flags — see `ownsSections`. The section scope above still applies.
|
|
703
|
+
*/
|
|
704
|
+
if (ownsSections)
|
|
705
|
+
return true;
|
|
700
706
|
const path = entry.url.startsWith("http")
|
|
701
707
|
? new URL(entry.url).pathname
|
|
702
708
|
: entry.url;
|
|
@@ -64,6 +64,29 @@ export const PORTAL_DEFINITIONS = [
|
|
|
64
64
|
* this module exists to end.
|
|
65
65
|
*/
|
|
66
66
|
{ label: "auth", section: "/auth", roles: [], home: "/auth/login" },
|
|
67
|
+
/*
|
|
68
|
+
* ── help: a PORTAL, not a deployment (owner, 2026-11-09) ──────────────
|
|
69
|
+
*
|
|
70
|
+
* The plan had `help.<domain>` down as its own app alongside blogs and
|
|
71
|
+
* events. The owner's answer was "do like dashboards" — i.e. a host rewrite
|
|
72
|
+
* onto the main app, the same treatment `admin.`/`seller.`/`user.` get, and
|
|
73
|
+
* NOT a deployment.
|
|
74
|
+
*
|
|
75
|
+
* It is the right call for this surface: `/help` is six content pages with
|
|
76
|
+
* ZERO API routes (measured 2026-11-09). Everything the subdomain split buys
|
|
77
|
+
* — an independently deployable owner of its own data, exposing CRUD over
|
|
78
|
+
* HTTP — is worth nothing when there is no data and no CRUD. It would be a
|
|
79
|
+
* whole deployment, Vercel project, env set and CORS gate to serve six static
|
|
80
|
+
* pages the shop already renders.
|
|
81
|
+
*
|
|
82
|
+
* Consequently `help` is REMOVED from DEPLOYMENT_LABELS below. A label must
|
|
83
|
+
* be in exactly one of the two lists: in both, the deployment check wins and
|
|
84
|
+
* the rewrite silently never fires.
|
|
85
|
+
*
|
|
86
|
+
* `roles: []` like `auth` — the help centre is public, and a visitor with no
|
|
87
|
+
* account is precisely who needs it.
|
|
88
|
+
*/
|
|
89
|
+
{ label: "help", section: "/help", roles: [] },
|
|
67
90
|
];
|
|
68
91
|
/**
|
|
69
92
|
* Hosts that are their OWN DEPLOYMENT, not a portal of this app.
|
|
@@ -93,8 +116,20 @@ export const DEPLOYMENT_LABELS = [
|
|
|
93
116
|
"blogs",
|
|
94
117
|
"live",
|
|
95
118
|
"media",
|
|
96
|
-
|
|
97
|
-
|
|
119
|
+
/*
|
|
120
|
+
* 🛑 `help` WAS HERE and has moved to PORTAL_DEFINITIONS above — the
|
|
121
|
+
* owner chose a host rewrite over a deployment for it (2026-11-09). A label
|
|
122
|
+
* in BOTH lists is the bug this note exists to prevent: `isDeploymentHost`
|
|
123
|
+
* is consulted first, so the portal rewrite would silently never fire and
|
|
124
|
+
* `help.<domain>` would fall through to the homepage — exactly the duplicate
|
|
125
|
+
* content CLAUDE.md records for `audit.` and `tools.`.
|
|
126
|
+
*
|
|
127
|
+
* ⚠ `chat` IS ALSO ABSENT, and for a different reason: there is nothing to
|
|
128
|
+
* serve. `/chat` has ZERO pages in the shop (measured 2026-11-09), so making
|
|
129
|
+
* it a portal would rewrite `chat.<domain>` onto a 404, and making it a
|
|
130
|
+
* deployment would point a hostname at an app that does not exist. It joins
|
|
131
|
+
* one list or the other when it has a surface — not before.
|
|
132
|
+
*/
|
|
98
133
|
];
|
|
99
134
|
/** Is this hostname a separate deployment rather than a portal of this app? */
|
|
100
135
|
export function isDeploymentHost(hostname) {
|