@juspay/svelte-ui-components 4.27.6 → 4.28.1

package/dist/types.d.ts

@@ -8,8 +8,10 @@ import type { HTMLAttributes } from 'svelte/elements';
  * which native types a consumer may ask for. The four added beyond the original
  * text/tel/password/email/number all keep `value` a plain string with no parallel
  * `checked`/`files` model, so Input's existing value plumbing covers them unchanged.
- * `validateInput()` switches on dataType with no default branch, and `number` has
- * always fallen through it unvalidated — these fall through identically.
+ * `validateInput()` switches on dataType with no default branch, so `number`,
+ * `time`, `date`, `search` and `url` are never validated by it and are always
+ * reported Valid. That limit is stated on `Input`'s own `dataType` prop too — a
+ * consumer picking a dataType reads the prop, not this union.
  *
  * Deliberately NOT included: checkbox and radio (driven by `checked`, which Input has
  * no prop for), and file (rejects scripted `value` writes outright). Those need new

package/dist/utils.d.ts

@@ -1,4 +1,41 @@
 import type { CustomValidator, Hsv, Hsl, InputDataType, Rgb, ValidationState } from './types';
+/**
+ * A phone-number shape a consumer opts into, as the pair of patterns the
+ * in-progress/committed distinction needs.
+ *
+ * Presets exist because `tel` cannot have a correct universal *format* rule --
+ * only a universal *character* rule (see `validateE164Shape`). A market-specific
+ * format is a real requirement and belongs to whoever knows the market, so it is
+ * named, exported and opted into rather than assumed.
+ */
+export type TelPreset = {
+    /** Matches a complete, committed number. */
+    readonly valid: RegExp;
+    /** Matches a number still being typed. Must accept every prefix of `valid`. */
+    readonly inProgress: RegExp;
+};
+/**
+ * Ten digits beginning 6-9 -- an Indian mobile number.
+ *
+ * This was the UNCONDITIONAL default for `dataType="tel"`. A consumer outside
+ * India got `+33 6 12 34 56 78` and `(555) 123-4567` marked Invalid by a rule
+ * they never chose and could not see, which is the worst shape for a default to
+ * fail in: correct input, silently rejected, no message naming the market.
+ * It is still here, still correct for the market it describes, and now has to be
+ * asked for.
+ */
+export declare const TEL_PRESET_IN_MOBILE: TelPreset;
+/** Every preset this library ships, by name. */
+export declare const TEL_PRESETS: Readonly<Record<string, TelPreset>>;
+/** Optional, additive settings for `validateInput`. */
+export type ValidateInputOptions = {
+    /**
+     * Format rule for `dataType="tel"` when no `validPattern` is supplied. Null or
+     * omitted keeps the locale-neutral character check described on
+     * `validateInput`.
+     */
+    readonly telPreset?: TelPreset | null;
+};
 /**
  * @description A common function to validate value provided inside the input component
  * @param inputValue String value coming from input field
@@ -6,9 +43,23 @@ import type { CustomValidator, Hsv, Hsl, InputDataType, Rgb, ValidationState } f
  * @param validPattern Regular expression which is supposed to be applied on the input string
  * @param inProgressPattern Regular expression which is supposed to be applied on the input string while input is in progress
  * @param customValidators Array of customer validator functions
+ * @param options Optional settings; see `ValidateInputOptions`
  * @returns ValidationState : InProgress | Valid | Invalid
+ *
+ * Only `email`, `tel`, `password` and `text` are validated here. `number`,
+ * `time`, `date`, `search` and `url` have NO branch and always return 'Valid'
+ * before custom validators run -- the browser's own constraint validation is the
+ * only thing checking them. That is a real gap rather than a deliberate policy,
+ * and it is stated on `Input`'s `dataType` prop as well as here, because a
+ * consumer choosing a dataType reads the prop and not this file.
+ *
+ * `tel` with no `validPattern` checks the CHARACTERS a number may contain and
+ * nothing about its national format (see `validateE164Shape`). It used to apply
+ * an Indian mobile pattern unconditionally; that rule is now
+ * `TEL_PRESET_IN_MOBILE`, passed through `options.telPreset` here or through
+ * `Input`'s `validationPattern` / `inProgressPattern` props.
  */
-export declare function validateInput(inputValue: string, dataType: InputDataType, validPattern: RegExp | null, inProgressPattern: RegExp | null, customValidators: CustomValidator[]): ValidationState;
+export declare function validateInput(inputValue: string, dataType: InputDataType, validPattern: RegExp | null, inProgressPattern: RegExp | null, customValidators: CustomValidator[], options?: ValidateInputOptions): ValidationState;
 /**
  * @description Creates a debouncer function that delays invoking the provided callback until a specified delay period has elapsed since the last invocation.
  * @param delay The delay period in milliseconds before invoking the callback.
@@ -35,6 +86,16 @@ export declare function clampInt(v: string, min: number, max: number): number;
  * bubble and leaves it running in the message body rendered inside it.
  */
 export declare function prefersReducedMotion(): boolean;
+/**
+ * Leading-edge throttle, despite the name: the first call runs immediately and
+ * every call within `delay` of it is dropped, rather than the last one being
+ * deferred as a debounce would. Modal relies on exactly that — the first
+ * dismissal must be acted on at once, and the repeats it guards against are the
+ * ones to discard.
+ *
+ * Not exported from the package; renaming it is a free change whenever the
+ * mismatch stops being worth the note.
+ */
 export declare function createDebouncer(delay: number): <T extends unknown[]>(callback: (...args: T) => void, ...args: T) => void;
 export declare function lockBodyScroll(): void;
 export declare function unlockBodyScroll(): void;

package/dist/utils.js

@@ -1,3 +1,48 @@
+/**
+ * Ten digits beginning 6-9 -- an Indian mobile number.
+ *
+ * This was the UNCONDITIONAL default for `dataType="tel"`. A consumer outside
+ * India got `+33 6 12 34 56 78` and `(555) 123-4567` marked Invalid by a rule
+ * they never chose and could not see, which is the worst shape for a default to
+ * fail in: correct input, silently rejected, no message naming the market.
+ * It is still here, still correct for the market it describes, and now has to be
+ * asked for.
+ */
+export const TEL_PRESET_IN_MOBILE = {
+    valid: /^[6-9][0-9]{9}$/,
+    inProgress: /^[6-9][0-9]{0,9}$/
+};
+/** Every preset this library ships, by name. */
+export const TEL_PRESETS = {
+    'in-mobile': TEL_PRESET_IN_MOBILE
+};
+/** Digits a number can hold under E.164, which caps the subscriber number at 15. */
+const E164_MAX_DIGITS = 15;
+/** Shortest real number anywhere; below this a number is still being typed. */
+const TEL_MIN_DIGITS = 4;
+/**
+ * The only rule about phone numbers that holds in every market: which
+ * CHARACTERS one may contain, and how many digits it may hold. Length, leading
+ * digit and grouping are all national, so none of them are asserted here.
+ *
+ * Rejects letters and stray punctuation, accepts `+33 6 12 34 56 78`,
+ * `(555) 123-4567` and `9876543210` alike.
+ */
+function validateE164Shape(phoneNumber) {
+    if (phoneNumber.length === 0) {
+        return 'InProgress';
+    }
+    // A leading + is part of the international prefix and may appear only first.
+    const body = phoneNumber.startsWith('+') ? phoneNumber.slice(1) : phoneNumber;
+    if (/[^0-9\s()\-.]/.test(body)) {
+        return 'Invalid';
+    }
+    const digits = body.replace(/[^0-9]/g, '');
+    if (digits.length > E164_MAX_DIGITS) {
+        return 'Invalid';
+    }
+    return digits.length >= TEL_MIN_DIGITS ? 'Valid' : 'InProgress';
+}
 /**
  * @description A common function to validate value provided inside the input component
  * @param inputValue String value coming from input field
@@ -5,9 +50,23 @@
  * @param validPattern Regular expression which is supposed to be applied on the input string
  * @param inProgressPattern Regular expression which is supposed to be applied on the input string while input is in progress
  * @param customValidators Array of customer validator functions
+ * @param options Optional settings; see `ValidateInputOptions`
  * @returns ValidationState : InProgress | Valid | Invalid
+ *
+ * Only `email`, `tel`, `password` and `text` are validated here. `number`,
+ * `time`, `date`, `search` and `url` have NO branch and always return 'Valid'
+ * before custom validators run -- the browser's own constraint validation is the
+ * only thing checking them. That is a real gap rather than a deliberate policy,
+ * and it is stated on `Input`'s `dataType` prop as well as here, because a
+ * consumer choosing a dataType reads the prop and not this file.
+ *
+ * `tel` with no `validPattern` checks the CHARACTERS a number may contain and
+ * nothing about its national format (see `validateE164Shape`). It used to apply
+ * an Indian mobile pattern unconditionally; that rule is now
+ * `TEL_PRESET_IN_MOBILE`, passed through `options.telPreset` here or through
+ * `Input`'s `validationPattern` / `inProgressPattern` props.
  */
-export function validateInput(inputValue, dataType, validPattern, inProgressPattern, customValidators) {
+export function validateInput(inputValue, dataType, validPattern, inProgressPattern, customValidators, options = {}) {
     let validationResult = 'Valid';
     switch (dataType) {
         case 'email':
@@ -16,7 +75,7 @@ export function validateInput(inputValue, dataType, validPattern, inProgressPatt
         case 'tel':
             validationResult =
                 validPattern === null
-                    ? validatePhoneNumber(inputValue)
+                    ? validatePhoneNumber(inputValue, options.telPreset ?? null)
                     : validateTextWithPattern(inputValue, validPattern, inProgressPattern);
             break;
         case 'password':
@@ -118,30 +177,20 @@ function validateEmailInput(emailId) {
     return 'Valid';
 }
 /**
- * @description Validates Indian phone numbers
- * @todo Update Regex to take different variations of input in next update
- * @link https://stackoverflow.com/questions/18351553/regular-expression-validation-for-indian-phone-number-and-mobile-number
+ * @description Validates a phone number against an opted-in preset, or against
+ * the locale-neutral character rule when none is given.
  * @param phoneNumber
+ * @param preset Market-specific format, or null for no format rule at all
  * @returns ValidationState
  */
-function validatePhoneNumber(phoneNumber) {
-    try {
-        const validationPattern = new RegExp('^[6-9]{1}[0-9]{9}$');
-        const inProgressPattern = new RegExp('^[6-9]{1}[0-9]{0,9}$');
-        if (validationPattern.test(phoneNumber)) {
-            return 'Valid';
-        }
-        else if (inProgressPattern.test(phoneNumber) || phoneNumber.length === 0) {
-            return 'InProgress';
-        }
-        else {
-            return 'Invalid';
-        }
+function validatePhoneNumber(phoneNumber, preset) {
+    if (preset === null) {
+        return validateE164Shape(phoneNumber);
     }
-    catch (e) {
-        console.error('Phone Regex creation failed', e);
+    if (preset.valid.test(phoneNumber)) {
+        return 'Valid';
     }
-    return phoneNumber.length === 10 ? 'Valid' : phoneNumber.length > 10 ? 'InProgress' : 'Invalid';
+    return preset.inProgress.test(phoneNumber) || phoneNumber.length === 0 ? 'InProgress' : 'Invalid';
 }
 /**
  * @description Creates a debouncer function that delays invoking the provided callback until a specified delay period has elapsed since the last invocation.
@@ -296,6 +345,16 @@ export function prefersReducedMotion() {
         typeof window.matchMedia === 'function' &&
         window.matchMedia('(prefers-reduced-motion: reduce)').matches);
 }
+/**
+ * Leading-edge throttle, despite the name: the first call runs immediately and
+ * every call within `delay` of it is dropped, rather than the last one being
+ * deferred as a debounce would. Modal relies on exactly that — the first
+ * dismissal must be acted on at once, and the repeats it guards against are the
+ * ones to discard.
+ *
+ * Not exported from the package; renaming it is a free change whenever the
+ * mismatch stops being worth the note.
+ */
 export function createDebouncer(delay) {
     let lastCallTime = 0;
     return function (callback, ...args) {

package/dist-codemod/{bin.js → codemod/bin.js}

@@ -6,6 +6,17 @@
 // not reuse cli.ts's own "am I the entry point" check — the bin is reached
 // through an npm symlink, whose path never matches the real module URL, so
 // that check would silently run nothing.
+//
+// This same check also gates the `migrate` subcommand (migrate-audit.ts):
+// it imports `analyzeStylesheet`/`analyzeSvelte` from `../migrate/analyze.ts`,
+// which imports `svelte/compiler` at module load too — unconditionally, for
+// both functions, since that import sits above the split between them. This
+// check runs, and can fail, before `cli.ts` is even imported, so it covers
+// that path regardless of how `cli.ts` itself reaches migrate-audit.ts —
+// which it now does with a dynamic `import()` inside `run` (see that
+// function's doc comment in cli.ts), specifically so the classic prop-rename
+// command below does not pay this same resolution cost, or fail the same
+// way, for a dependency only the audit needs.
 const REQUIRED = ['svelte/compiler'];
 const missing = REQUIRED.filter((specifier) => {
     try {
@@ -23,8 +34,8 @@ if (missing.length > 0) {
     process.exitCode = 1;
 }
 else {
-    const { runCodemod } = await import("./cli.js");
-    const summary = runCodemod(process.argv.slice(2), (line) => {
+    const { run } = await import("./cli.js");
+    const summary = await run(process.argv.slice(2), (line) => {
         console.log(line);
     });
     process.exitCode = summary.exitCode;

package/dist-codemod/{cli.js → codemod/cli.js}

@@ -6,6 +6,7 @@ import { transformSvelte } from "./transform.js";
 import { findChildrenAssignments } from "./wc-children.js";
 const USAGE = [
     'Usage: npx sui-codemod [--dry-run] <path...>',
+    '       npx sui-codemod migrate [--dry-run] <path>',
     '       (inside this repository: node scripts/codemod/cli.ts ...)',
     '',
     'Prepares a @juspay/svelte-ui-components consumer for 4.0.0: renames every',
@@ -18,9 +19,17 @@ const USAGE = [
     '',
     'Paths may be files or directories; directories are walked recursively,',
     'skipping node_modules, .git, .svelte-kit, dist, dist-wc, build, coverage,',
-    'playwright-report and test-results.'
+    'playwright-report and test-results.',
+    '',
+    'Run `sui-codemod migrate <path> --help` instead to audit a project for',
+    'the seven 4.28.0 breaking changes (a different, single-project subcommand',
+    '-- see migrate-audit.ts).'
 ].join('\n');
-const SKIPPED_DIRECTORIES = new Set([
+/**
+ * Exported for `migrate-audit.ts`'s own consumer file walk, so the two
+ * subcommands can never drift on what "skip node_modules et al." means.
+ */
+export const SKIPPED_DIRECTORIES = new Set([
     'node_modules',
     '.git',
     '.svelte-kit',
@@ -166,9 +175,45 @@ export function runCodemod(argv, log) {
         warnings
     };
 }
+/**
+ * `sui-codemod`'s single entry point, callable directly by `bin.ts` and by
+ * tests: a leading `migrate` positional routes to the 4.28.0 breaking-change
+ * audit (`migrate-audit.ts`), matching `npm run migrate`'s findings but
+ * runnable against a project that only has the published package installed;
+ * anything else goes to `runCodemod`, unchanged from before this existed.
+ *
+ * A subcommand rather than a flag (`--migrate`) because the two take a
+ * different argv shape -- `runCodemod` accepts a variadic list of paths,
+ * `migrate` takes exactly one project root, mirroring `chart-tooltip-selector.ts`
+ * and `scripts/migrate/cli.ts` -- and because `migrate`'s own `--dry-run`
+ * means "preview the tooltip selector rewrite", a different question from
+ * `runCodemod`'s "preview the prop rename", so the two need separate
+ * `parseArgs` calls rather than one shared flag set. The trade-off is a
+ * consumer directory literally named `migrate` colliding with the
+ * subcommand if passed as this package's own single positional; no such
+ * conflict exists for `runCodemod`'s variadic form.
+ *
+ * `migrate-audit.ts` is imported dynamically here, inside the branch that
+ * actually needs it, rather than as a static top-level import. A static
+ * import is resolved and linked -- by Node, at module load, before any of
+ * this file's own code runs -- regardless of whether `argv` ever asks for
+ * `migrate`; `migrate-audit.ts` in turn imports `../migrate/analyze.ts`
+ * unconditionally, so a static import here would mean every invocation of
+ * `runCodemod`'s own prop-rename command, the one this package has shipped
+ * since 4.0.0, pays that resolution cost too, and fails outright if it
+ * can't be satisfied. A dynamic import defers that cost, and that failure
+ * mode, to only the invocations that actually take this branch.
+ */
+export async function run(argv, log) {
+    if (argv[0] === 'migrate') {
+        const { runMigrateAudit } = await import("./migrate-audit.js");
+        return runMigrateAudit(argv.slice(1), log);
+    }
+    return runCodemod(argv, log);
+}
 const entryPoint = process.argv.at(1) ?? '';
 if (entryPoint !== '' && import.meta.url === pathToFileURL(entryPoint).href) {
-    const summary = runCodemod(process.argv.slice(2), (line) => {
+    const summary = await run(process.argv.slice(2), (line) => {
         console.log(line);
     });
     process.exitCode = summary.exitCode;