@d-zero/page-cluster 0.2.0

package/dist/resolve-blocking-group-keys.d.ts

@@ -0,0 +1,116 @@
+/**
+ * The two blocking signals {@link ./derive-path-group-key.js | derivePathGroupKey}
+ * and {@link ./derive-stylesheet-group-key.js | deriveStylesheetGroupKey} need,
+ * bundled per page so `resolveBlockingGroupKeys` can compute both without the
+ * caller re-deriving them separately.
+ */
+export type PageBlockingSignals = {
+    paths: readonly string[];
+    stylesheetHrefs: readonly string[];
+};
+/**
+ * @see resolveBlockingGroupKeys
+ */
+export type ResolveBlockingGroupKeysOptions = {
+    /** Forwarded to `derivePathGroupKey` as-is. */
+    pathDepth?: number;
+    /**
+     * Minimum number of pages that must share a stylesheet-derived key before
+     * it's trusted as real evidence, rather than a coincidence. Must be at
+     * least 2: a page always "shares" its own key with itself, so 1 would
+     * accept every stylesheet-bearing page unconditionally and make this
+     * check a no-op. This is a structural floor (below 2, no pair of distinct
+     * pages can exist at all), not a statistically-derived
+     * confidence threshold — entity-resolution blocking literature has no
+     * closed-form value for "how many shared pages prove a true match", so
+     * this is a starting default to be tuned against real corpora, not a
+     * validated constant.
+     */
+    minCssGroupSize?: number;
+    /** Forwarded to `splitTokensByFrequency` as-is. */
+    hrefCommonThreshold?: number;
+};
+/**
+ * Resolves, per page, which of the two independent blocking signals — the
+ * exact stylesheet set or the URL path — to actually use as that page's
+ * grouping key. Returns one key per page, in the same order as `pages`.
+ *
+ * Literature on entity-resolution blocking (Michelson & Knoblock's DNF
+ * scheme, canopy clustering, ensemble blocking) combines independent
+ * blocking predicates with OR to generate *candidate pairs* for a later
+ * similarity/classification pass. This function instead commits each page to
+ * exactly one final key: `resolve-page-cluster-keys.js`'s
+ * `resolvePageClusterKeys` *does* run a later refinement step
+ * (`resolveStructuralClusterKeys`) on top of whichever key a page lands on,
+ * but only within that one key's candidate pool — it has no way to pull in
+ * a page that this function routed to a different key. So this function's
+ * per-page choice is still effectively final for blocking purposes: a page
+ * assigned to the wrong key here never re-enters the correct key's pool
+ * downstream. A true OR-merge (letting a page carry both the stylesheet and
+ * path candidates, deferring to the refinement step to reconcile overlapping
+ * results across them) would close that gap, but is deliberately deferred —
+ * it needs the same literature-plus-real-data validation cycle this
+ * package's linkage-criterion and NN-chain choices already went through, not
+ * a change bundled in alongside unrelated fixes. Until then, a
+ * priority-with-fallback decision — try the strong signal, fall back to the
+ * weak one — is the applicable pattern here, not OR-merge: a union of
+ * equivalence relations can only ever coarsen a partition, never split it,
+ * but the whole point of preferring the stylesheet signal is that it *splits*
+ * pages a URL-path-only grouping would otherwise lump together (confirmed
+ * against real crawl data: a single page embedded under an otherwise-uniform
+ * URL section, but loading a completely different stylesheet set, is exactly
+ * the case a path-only key misses and a stylesheet key catches).
+ *
+ * Before comparing stylesheet sets, this reuses
+ * {@link ./compute-document-frequency.js | computeDocumentFrequency} and
+ * {@link ./split-tokens-by-frequency.js | splitTokensByFrequency} — originally
+ * built to separate a page's site-wide chrome from its page-specific HTML
+ * structure — to strip stylesheet hrefs that recur across most of `pages`
+ * (e.g. a shared reset/font stylesheet) before hashing. Without this, two
+ * pages from otherwise-unrelated sections that happen to load only that one
+ * shared stylesheet would satisfy `minCssGroupSize` and be wrongly treated as
+ * the same template family: the problem there isn't too few pages sharing
+ * the key (raising `minCssGroupSize` doesn't fix it), it's that the key
+ * itself carries no discriminative information. A page whose stylesheet set
+ * is empty, or becomes empty after this filtering, always falls back to the
+ * path key — loading no distinctive stylesheet is an absence of evidence,
+ * not evidence of a shared template, so it must never itself become a
+ * matching signal.
+ *
+ * Document frequency is computed only over pages that load at least one
+ * stylesheet: including stylesheet-less pages in the denominator would dilute
+ * every href's frequency ratio (e.g. a stylesheet loaded by 100% of the pages
+ * that load *any* stylesheet would read as a low, "distinctive" frequency if
+ * most pages in the batch load none), letting a genuinely non-discriminative,
+ * site-wide stylesheet slip through the common-href filter.
+ *
+ * Like `computeDocumentFrequency` itself, this expects `pages` to be a
+ * roughly homogeneous batch (one site, or one section of a large
+ * multi-template site) — see that function's JSDoc for why a federation of
+ * independently-templated sub-sections defeats frequency-based filtering.
+ * Splitting a heterogeneous crawl into sections before calling this function
+ * is the caller's responsibility.
+ *
+ * This filtering needs enough stylesheet-bearing pages to tell "loaded by
+ * every page that has any stylesheet" apart from "coincidentally the only
+ * stylesheet two pages happen to load": with only two stylesheet-bearing
+ * pages in the whole batch and nothing else to contrast against, any
+ * stylesheet they share reads as 100% common and gets filtered out,
+ * producing a path-key fallback even when the two pages are a genuine
+ * template match. A third, differently-styled page (as in the example below)
+ * is what gives the shared stylesheet a frequency below the common-href
+ * cutoff.
+ * @param pages
+ * @param options
+ * @example
+ * ```ts
+ * resolveBlockingGroupKeys([
+ * 	{ paths: ['dept-a', 'news', '1'], stylesheetHrefs: ['https://example.com/a.css', 'https://example.com/common.css'] },
+ * 	{ paths: ['dept-a', 'news', '2'], stylesheetHrefs: ['https://example.com/a.css', 'https://example.com/common.css'] },
+ * 	{ paths: ['dept-b', 'about'], stylesheetHrefs: ['https://example.com/common.css'] },
+ * ]);
+ * // ['css:<hash of a.css>', 'css:<hash of a.css>', 'path:dept-b']
+ * // common.css is loaded by all 3 pages and is filtered out as non-discriminative chrome.
+ * ```
+ */
+export declare function resolveBlockingGroupKeys(pages: readonly PageBlockingSignals[], options?: ResolveBlockingGroupKeysOptions): string[];

package/dist/resolve-blocking-group-keys.js

@@ -0,0 +1,120 @@
+import { computeDocumentFrequency } from './compute-document-frequency.js';
+import { derivePathGroupKey } from './derive-path-group-key.js';
+import { deriveStylesheetGroupKey } from './derive-stylesheet-group-key.js';
+import { splitTokensByFrequency } from './split-tokens-by-frequency.js';
+const DEFAULT_MIN_CSS_GROUP_SIZE = 2;
+/**
+ * Resolves, per page, which of the two independent blocking signals — the
+ * exact stylesheet set or the URL path — to actually use as that page's
+ * grouping key. Returns one key per page, in the same order as `pages`.
+ *
+ * Literature on entity-resolution blocking (Michelson & Knoblock's DNF
+ * scheme, canopy clustering, ensemble blocking) combines independent
+ * blocking predicates with OR to generate *candidate pairs* for a later
+ * similarity/classification pass. This function instead commits each page to
+ * exactly one final key: `resolve-page-cluster-keys.js`'s
+ * `resolvePageClusterKeys` *does* run a later refinement step
+ * (`resolveStructuralClusterKeys`) on top of whichever key a page lands on,
+ * but only within that one key's candidate pool — it has no way to pull in
+ * a page that this function routed to a different key. So this function's
+ * per-page choice is still effectively final for blocking purposes: a page
+ * assigned to the wrong key here never re-enters the correct key's pool
+ * downstream. A true OR-merge (letting a page carry both the stylesheet and
+ * path candidates, deferring to the refinement step to reconcile overlapping
+ * results across them) would close that gap, but is deliberately deferred —
+ * it needs the same literature-plus-real-data validation cycle this
+ * package's linkage-criterion and NN-chain choices already went through, not
+ * a change bundled in alongside unrelated fixes. Until then, a
+ * priority-with-fallback decision — try the strong signal, fall back to the
+ * weak one — is the applicable pattern here, not OR-merge: a union of
+ * equivalence relations can only ever coarsen a partition, never split it,
+ * but the whole point of preferring the stylesheet signal is that it *splits*
+ * pages a URL-path-only grouping would otherwise lump together (confirmed
+ * against real crawl data: a single page embedded under an otherwise-uniform
+ * URL section, but loading a completely different stylesheet set, is exactly
+ * the case a path-only key misses and a stylesheet key catches).
+ *
+ * Before comparing stylesheet sets, this reuses
+ * {@link ./compute-document-frequency.js | computeDocumentFrequency} and
+ * {@link ./split-tokens-by-frequency.js | splitTokensByFrequency} — originally
+ * built to separate a page's site-wide chrome from its page-specific HTML
+ * structure — to strip stylesheet hrefs that recur across most of `pages`
+ * (e.g. a shared reset/font stylesheet) before hashing. Without this, two
+ * pages from otherwise-unrelated sections that happen to load only that one
+ * shared stylesheet would satisfy `minCssGroupSize` and be wrongly treated as
+ * the same template family: the problem there isn't too few pages sharing
+ * the key (raising `minCssGroupSize` doesn't fix it), it's that the key
+ * itself carries no discriminative information. A page whose stylesheet set
+ * is empty, or becomes empty after this filtering, always falls back to the
+ * path key — loading no distinctive stylesheet is an absence of evidence,
+ * not evidence of a shared template, so it must never itself become a
+ * matching signal.
+ *
+ * Document frequency is computed only over pages that load at least one
+ * stylesheet: including stylesheet-less pages in the denominator would dilute
+ * every href's frequency ratio (e.g. a stylesheet loaded by 100% of the pages
+ * that load *any* stylesheet would read as a low, "distinctive" frequency if
+ * most pages in the batch load none), letting a genuinely non-discriminative,
+ * site-wide stylesheet slip through the common-href filter.
+ *
+ * Like `computeDocumentFrequency` itself, this expects `pages` to be a
+ * roughly homogeneous batch (one site, or one section of a large
+ * multi-template site) — see that function's JSDoc for why a federation of
+ * independently-templated sub-sections defeats frequency-based filtering.
+ * Splitting a heterogeneous crawl into sections before calling this function
+ * is the caller's responsibility.
+ *
+ * This filtering needs enough stylesheet-bearing pages to tell "loaded by
+ * every page that has any stylesheet" apart from "coincidentally the only
+ * stylesheet two pages happen to load": with only two stylesheet-bearing
+ * pages in the whole batch and nothing else to contrast against, any
+ * stylesheet they share reads as 100% common and gets filtered out,
+ * producing a path-key fallback even when the two pages are a genuine
+ * template match. A third, differently-styled page (as in the example below)
+ * is what gives the shared stylesheet a frequency below the common-href
+ * cutoff.
+ * @param pages
+ * @param options
+ * @example
+ * ```ts
+ * resolveBlockingGroupKeys([
+ * 	{ paths: ['dept-a', 'news', '1'], stylesheetHrefs: ['https://example.com/a.css', 'https://example.com/common.css'] },
+ * 	{ paths: ['dept-a', 'news', '2'], stylesheetHrefs: ['https://example.com/a.css', 'https://example.com/common.css'] },
+ * 	{ paths: ['dept-b', 'about'], stylesheetHrefs: ['https://example.com/common.css'] },
+ * ]);
+ * // ['css:<hash of a.css>', 'css:<hash of a.css>', 'path:dept-b']
+ * // common.css is loaded by all 3 pages and is filtered out as non-discriminative chrome.
+ * ```
+ */
+export function resolveBlockingGroupKeys(pages, options) {
+    const pathDepth = options?.pathDepth;
+    const minCssGroupSize = options?.minCssGroupSize ?? DEFAULT_MIN_CSS_GROUP_SIZE;
+    const hrefCommonThreshold = options?.hrefCommonThreshold;
+    if (!(Number.isInteger(minCssGroupSize) && minCssGroupSize >= 2)) {
+        throw new RangeError(`resolveBlockingGroupKeys: minCssGroupSize must be an integer >= 2, got ${minCssGroupSize}`);
+    }
+    // Eagerly delegate pathDepth/hrefCommonThreshold validation to the
+    // functions that own it, instead of only discovering an invalid option
+    // once some page's data happens to reach that branch below.
+    derivePathGroupKey([], pathDepth);
+    splitTokensByFrequency(new Set(), { documentFrequency: new Map(), pageCount: 0 }, hrefCommonThreshold);
+    const hrefSets = pages.map((page) => new Set(page.stylesheetHrefs));
+    // Pages with no stylesheets at all must not count toward the denominator:
+    // see the JSDoc note above on document-frequency dilution.
+    const corpusFrequency = computeDocumentFrequency(hrefSets.filter((hrefSet) => hrefSet.size > 0));
+    const distinctiveHrefs = hrefSets.map((hrefSet) => splitTokensByFrequency(hrefSet, corpusFrequency, hrefCommonThreshold).contentTokens);
+    const cssKeys = distinctiveHrefs.map((hrefs) => hrefs.size === 0 ? undefined : deriveStylesheetGroupKey([...hrefs]));
+    const cssKeyCounts = new Map();
+    for (const cssKey of cssKeys) {
+        if (cssKey !== undefined) {
+            cssKeyCounts.set(cssKey, (cssKeyCounts.get(cssKey) ?? 0) + 1);
+        }
+    }
+    return pages.map((page, index) => {
+        const cssKey = cssKeys[index];
+        if (cssKey !== undefined && (cssKeyCounts.get(cssKey) ?? 0) >= minCssGroupSize) {
+            return `css:${cssKey}`;
+        }
+        return `path:${derivePathGroupKey(page.paths, pathDepth)}`;
+    });
+}

package/dist/resolve-closed-frame.d.ts

@@ -0,0 +1,26 @@
+import type { Frame } from './types.js';
+/**
+ * Resolves a frame once its element has closed, returning the leaf paths it
+ * contributes to its parent (still relative to the parent — the parent
+ * prefixes its own segment, if any, the next time *it* closes).
+ *
+ * Whether a `div`/`span` folds away can only be known once it closes (its
+ * final child count isn't settled until then), which is why this resolution
+ * happens here rather than eagerly when the element opens — see the module
+ * doc on `run-tokenizer.ts` for why a naive "emit on open" SAX pass cannot
+ * implement folding at all.
+ *
+ * An element with nothing in `pendingPaths` (e.g. an empty `<div class="spacer">`,
+ * or one with only text/whitespace children) is itself a leaf and returns its
+ * own segment; a folded wrapper contributes nothing of its own, passing its
+ * children's paths straight through so the wrapper's nesting depth carries no
+ * structural information (see the "何を捨てたか" note in `tokenize.ts`).
+ *
+ * Leaf-ness is judged by `pendingPaths`, not `childElementCount`: a comment
+ * (when `includeComments` is on) lands in `pendingPaths` without incrementing
+ * `childElementCount` (comments don't count toward fold eligibility either),
+ * so an element containing only a comment still has something to prefix and
+ * must not be treated as a plain leaf that discards it.
+ * @param frame
+ */
+export declare function resolveClosedFrame(frame: Frame): string[];

package/dist/resolve-closed-frame.js

@@ -0,0 +1,33 @@
+/**
+ * Resolves a frame once its element has closed, returning the leaf paths it
+ * contributes to its parent (still relative to the parent — the parent
+ * prefixes its own segment, if any, the next time *it* closes).
+ *
+ * Whether a `div`/`span` folds away can only be known once it closes (its
+ * final child count isn't settled until then), which is why this resolution
+ * happens here rather than eagerly when the element opens — see the module
+ * doc on `run-tokenizer.ts` for why a naive "emit on open" SAX pass cannot
+ * implement folding at all.
+ *
+ * An element with nothing in `pendingPaths` (e.g. an empty `<div class="spacer">`,
+ * or one with only text/whitespace children) is itself a leaf and returns its
+ * own segment; a folded wrapper contributes nothing of its own, passing its
+ * children's paths straight through so the wrapper's nesting depth carries no
+ * structural information (see the "何を捨てたか" note in `tokenize.ts`).
+ *
+ * Leaf-ness is judged by `pendingPaths`, not `childElementCount`: a comment
+ * (when `includeComments` is on) lands in `pendingPaths` without incrementing
+ * `childElementCount` (comments don't count toward fold eligibility either),
+ * so an element containing only a comment still has something to prefix and
+ * must not be treated as a plain leaf that discards it.
+ * @param frame
+ */
+export function resolveClosedFrame(frame) {
+    if (frame.pendingPaths.length === 0) {
+        return [frame.segment];
+    }
+    if (frame.isFoldCandidate && frame.childElementCount === 1) {
+        return frame.pendingPaths;
+    }
+    return frame.pendingPaths.map((path) => `${frame.segment}>${path}`);
+}

package/dist/resolve-landmark-variant-keys.d.ts

@@ -0,0 +1,66 @@
+import type { LandmarkType } from './extract-landmarks.js';
+import type { ResolveStructuralClusterKeysOptions } from './resolve-structural-cluster-keys.js';
+import type { TokenizeOptions } from './types.js';
+/**
+ * @see resolveLandmarkVariantKeys
+ */
+export type ResolveLandmarkVariantKeysOptions = TokenizeOptions & ResolveStructuralClusterKeysOptions;
+/**
+ * Classifies which *variant* of a single landmark type (e.g. "which header
+ * design") each page has, independently of
+ * {@link ./resolve-page-cluster-keys.js | resolvePageClusterKeys}'s overall
+ * per-page template key. This is metadata to attach to a page ("does it have
+ * header variant X?"), not a replacement for template clustering — callers
+ * that want both call this once per `landmarkType` alongside
+ * `resolvePageClusterKeys` and combine the results themselves; this function
+ * does not know about, or merge with, the other one's output.
+ *
+ * Each call re-runs {@link ./extract-landmarks.js | extractLandmarks} over
+ * the entire `htmlList`, keeping only the one field matching `landmarkType`
+ * and discarding the other three it also computed. Calling this once per
+ * `landmarkType` (as the paragraph above suggests, for a caller that wants
+ * more than one) therefore re-parses every page once per type requested. A
+ * caller for whom that cost is material should call `extractLandmarks`
+ * itself once per page, read all four fields off the single result, and feed
+ * each field's token sets to
+ * {@link ./resolve-structural-cluster-keys.js | resolveStructuralClusterKeys}
+ * directly (with the same empty-set sentinel for a missing field) instead of
+ * calling this function multiple times.
+ *
+ * A page with no match for `landmarkType` (per
+ * {@link ./extract-landmarks.js | extractLandmarks}) compares as an empty
+ * token set. `jaccardSimilarity`'s documented treatment of two empty sets as
+ * similarity `1` (see its JSDoc) means every landmark-less page lands in the
+ * same "has no such landmark" group with no extra branching needed here, and
+ * unambiguously in a different group from every page that does have one
+ * (`jaccardSimilarity(∅, nonEmpty)` is always `0`). A landmark that exists
+ * but is empty (e.g. `<header></header>`) never collides with this sentinel:
+ * `tokenize` still emits at least the element's own segment for it.
+ *
+ * Does not block by URL path or stylesheet first (unlike
+ * `resolvePageClusterKeys`): the same header design is normally reused
+ * across a site's independent URL sections, so blocking on those signals
+ * would work against this function's purpose. `resolveStructuralClusterKeys`
+ * is therefore given the full `htmlList` as one pool, which means this
+ * function inherits its O(n²) cost with no blocking to shrink `n` first —
+ * intended for batches of up to a few thousand pages (validated against an
+ * 800-page real sample), not for handing it an entire unblocked crawl.
+ * @param htmlList
+ * @param landmarkType
+ * @param options
+ * @example
+ * ```ts
+ * resolveLandmarkVariantKeys(
+ * 	[
+ * 		'<body><header><nav>A</nav></header></body>',
+ * 		'<body><header><nav>A</nav></header></body>',
+ * 		'<body><header><a>B</a></header></body>',
+ * 	],
+ * 	'header',
+ * );
+ * // pages 0 and 1 (structurally identical header) share a key; page 2 (a
+ * // different header structure) gets its own — text content alone (e.g.
+ * // the "A" vs "B" text) would not, since tokenize() discards visible text.
+ * ```
+ */
+export declare function resolveLandmarkVariantKeys(htmlList: readonly string[], landmarkType: LandmarkType, options?: ResolveLandmarkVariantKeysOptions): string[];

package/dist/resolve-landmark-variant-keys.js

@@ -0,0 +1,71 @@
+import { extractLandmarks } from './extract-landmarks.js';
+import { resolveStructuralClusterKeys } from './resolve-structural-cluster-keys.js';
+import { tokenize } from './tokenize.js';
+/**
+ * Classifies which *variant* of a single landmark type (e.g. "which header
+ * design") each page has, independently of
+ * {@link ./resolve-page-cluster-keys.js | resolvePageClusterKeys}'s overall
+ * per-page template key. This is metadata to attach to a page ("does it have
+ * header variant X?"), not a replacement for template clustering — callers
+ * that want both call this once per `landmarkType` alongside
+ * `resolvePageClusterKeys` and combine the results themselves; this function
+ * does not know about, or merge with, the other one's output.
+ *
+ * Each call re-runs {@link ./extract-landmarks.js | extractLandmarks} over
+ * the entire `htmlList`, keeping only the one field matching `landmarkType`
+ * and discarding the other three it also computed. Calling this once per
+ * `landmarkType` (as the paragraph above suggests, for a caller that wants
+ * more than one) therefore re-parses every page once per type requested. A
+ * caller for whom that cost is material should call `extractLandmarks`
+ * itself once per page, read all four fields off the single result, and feed
+ * each field's token sets to
+ * {@link ./resolve-structural-cluster-keys.js | resolveStructuralClusterKeys}
+ * directly (with the same empty-set sentinel for a missing field) instead of
+ * calling this function multiple times.
+ *
+ * A page with no match for `landmarkType` (per
+ * {@link ./extract-landmarks.js | extractLandmarks}) compares as an empty
+ * token set. `jaccardSimilarity`'s documented treatment of two empty sets as
+ * similarity `1` (see its JSDoc) means every landmark-less page lands in the
+ * same "has no such landmark" group with no extra branching needed here, and
+ * unambiguously in a different group from every page that does have one
+ * (`jaccardSimilarity(∅, nonEmpty)` is always `0`). A landmark that exists
+ * but is empty (e.g. `<header></header>`) never collides with this sentinel:
+ * `tokenize` still emits at least the element's own segment for it.
+ *
+ * Does not block by URL path or stylesheet first (unlike
+ * `resolvePageClusterKeys`): the same header design is normally reused
+ * across a site's independent URL sections, so blocking on those signals
+ * would work against this function's purpose. `resolveStructuralClusterKeys`
+ * is therefore given the full `htmlList` as one pool, which means this
+ * function inherits its O(n²) cost with no blocking to shrink `n` first —
+ * intended for batches of up to a few thousand pages (validated against an
+ * 800-page real sample), not for handing it an entire unblocked crawl.
+ * @param htmlList
+ * @param landmarkType
+ * @param options
+ * @example
+ * ```ts
+ * resolveLandmarkVariantKeys(
+ * 	[
+ * 		'<body><header><nav>A</nav></header></body>',
+ * 		'<body><header><nav>A</nav></header></body>',
+ * 		'<body><header><a>B</a></header></body>',
+ * 	],
+ * 	'header',
+ * );
+ * // pages 0 and 1 (structurally identical header) share a key; page 2 (a
+ * // different header structure) gets its own — text content alone (e.g.
+ * // the "A" vs "B" text) would not, since tokenize() discards visible text.
+ * ```
+ */
+export function resolveLandmarkVariantKeys(htmlList, landmarkType, options) {
+    const tokenSets = htmlList.map((html) => {
+        const region = extractLandmarks(html)[landmarkType];
+        if (region === undefined) {
+            return new Set();
+        }
+        return new Set(tokenize(`<body>${region}</body>`, options).tokens);
+    });
+    return resolveStructuralClusterKeys(tokenSets, options);
+}

package/dist/resolve-options.d.ts

@@ -0,0 +1,6 @@
+import type { ResolvedOptions, TokenizeOptions } from './types.js';
+/**
+ * Applies defaults to {@link TokenizeOptions}.
+ * @param options
+ */
+export declare function resolveOptions(options?: TokenizeOptions): ResolvedOptions;

package/dist/resolve-options.js

@@ -0,0 +1,10 @@
+/**
+ * Applies defaults to {@link TokenizeOptions}.
+ * @param options
+ */
+export function resolveOptions(options) {
+    return {
+        filterNoiseClasses: options?.filterNoiseClasses ?? true,
+        includeComments: options?.includeComments ?? false,
+    };
+}