12 Commits

Author	SHA1	Message	Date
Sanaei	92fb94d856	Move to TypeScript 7 and the oxc toolchain (oxlint + oxfmt) (#6262) ... * chore(frontend,docs): move to TypeScript 7 and replace ESLint with oxlint TypeScript 7 is the native Go port and ships no programmatic compiler API, so typescript-eslint cannot run at all: it peer-pins typescript >=4.8.4 <6.1.0 (canary too) and hard-crashes with "typescript-eslint does not support TS 7.0". Upstream support is tracked in typescript-eslint#10940 and targets TS >=7.1. Rather than wait, or carry Microsoft's side-by-side alias (which keeps a second TS 6 install alive purely to feed the linter), both projects move to oxlint, which never depended on the TypeScript API. Typecheck drops from ~9.7s to ~2.2s and 167 packages leave frontend/. oxlint has no no-restricted-syntax, so the #6121/#6127 cleared- InputNumber guard is reimplemented as a JS plugin in frontend/tools/oxlint/. It was verified to still fire in pages/settings/** and pages/xray/** and to stay exempt in *Modal.tsx. The type-aware @deprecated sweep survives too, as `npm run lint:deprecated`: oxlint's type-aware mode runs on oxlint-tsgolint, which drives the TS 7 typescript-go checker, so the TS 7 move is what makes it possible. Behaviour is preserved rather than tightened. jsx-a11y/prefer-tag-over-role is off in both configs because it was never part of the recommended sets ESLint actually ran, and oxlint honours the existing eslint-disable comments, so no source churn was needed. Two real fixes fell out of the stricter linting: - outbound-link-parser.test.ts used `out?.streamSettings` behind an `as` cast, which hid the optional chain from ESLint and would throw on a null parse; the rest of the file already used `out!`. - InputAddon's conditional role/tabIndex/onKeyDown is genuinely accessible but oxlint cannot evaluate it, so it gets a scoped disable. * chore(docs): replace Prettier with oxfmt oxfmt is the oxc project's Prettier-compatible formatter, so this pairs with the oxlint move and drops the last JS-based tool from the docs toolchain. The swap is behaviour-preserving. Running Prettier and oxfmt over the same files, with the existing .prettierrc.json settings migrated via `oxfmt --migrate=prettier`, produces byte-identical output on every file. (Comparing them outside the project directory is misleading: Prettier silently falls back to its defaults when it cannot find its config, which looks like a mismatch but is not one.) The 18 files reformatted here were already failing `pnpm format:check` before this change — Prettier wanted the exact same edits. The check is not part of docs-ci.yml, which is why the drift went unnoticed. .prettierignore becomes ignorePatterns in .oxfmtrc.json, keeping the deliberate MDX exclusion: reflowing MDX prose merges headings into paragraphs and collapses lists inside Steps/Callout components. Both that and the generated fumadocs-openapi reference output were verified untouched. oxfmt is pinned to 0.63.0 rather than latest. pnpm 11's built-in minimumReleaseAge policy rejects same-day releases, and 0.64.0 would have made pnpm silently append 20 waiver lines to pnpm-workspace.yaml. * style(frontend): adopt oxfmt and format src frontend/ has never had a formatter, so this reformats 344 of 497 files in src/. The change is purely whitespace, quoting and line wrapping — no logic is touched. It is kept in its own commit so it does not bury the TypeScript 7 / oxlint migration or the git blame for the code itself. Settings match docs/ and the code as it was already written: single quotes, semicolons, trailing commas, 2-space indent, 100 columns. That was measured rather than assumed — src/ was already uniformly single-quoted and 2-space indented, with p90 line length at 75. Formatting is scoped to src/ (mirroring `oxlint src`) and .oxfmtrc.json ignores src/generated. Both matter: `make gen-check` compares src/generated and public/openapi.json, and `make msw-worker-check` byte-compares public/mockServiceWorker.js against the installed MSW runtime, so reformatting any of them breaks the gate. Reflowing also moves `eslint-disable-next-line` comments off the line they guard, which broke two suppressions that had been silently correct before: - clone-inbound-modal.test.tsx: the object literal became multi-line, leaving `} as any;` four lines below its no-explicit-any disable. - ClientsPage.tsx: the useMemo dependency array moved onto its own line, out from under its exhaustive-deps disable. Both comments were relocated onto the line they actually guard, and verified to still suppress by removing them and watching the errors return. * ci: enforce formatting in CI and make verify Adding oxfmt in the previous two commits gave both projects a formatter but nothing that checks it, which is how docs/ had already drifted to 18 unformatted files: docs-ci.yml runs typecheck, lint, test and build, but never format:check, so Prettier's complaints were only ever visible to whoever ran it by hand. Wire `format:check` into the frontend job in ci.yml and the docs job in docs-ci.yml, and add a `format-check` target to `make verify` so the local gate keeps mirroring CI as the Makefile header promises. Verified the step actually bites rather than passing vacuously: adding a badly formatted line to a source file in each project makes both `make format-check` and `pnpm format:check` fail, and reverting it makes them pass again. No workflow referenced ESLint or Prettier by name — they all invoke the package scripts — so the tooling swap needed no other CI changes. * ci: trigger CI on Makefile changes The path filters listed **.go, go.mod, go.sum, frontend/**, .nvmrc and ci.yml itself, but not the Makefile — so a change to the canonical task runner that ci.yml is meant to mirror could land without any job running. The previous commit, which edits both, only triggers because it happens to touch ci.yml too. * fix(frontend): replace deprecated Ant Design 6 APIs in the geo components `npm run lint:deprecated` reported five uses of props Ant Design 6 has deprecated. All five are gone, and the matching runtime warnings no longer appear in the test output. Tag `bordered={false}` becomes `variant="filled"` and Space `direction` becomes `orientation`; both are the one-to-one replacements named in antd's own deprecation messages, and `direction`/`orientation` share the same Orientation type. Input `addonAfter` is the one that is not a rename. It becomes a `Space.Compact block` wrapping the Input and the browse Button, which is antd's documented migration. `block` keeps the field filling its form row as the addon did. Note this is a deliberate visual change: the button used to be a borderless `type="text"` icon sitting inside the addon's grey box, and is now a regular button whose border joins the input. The tooltip, aria-label, ref, id and onBlur wiring are unchanged, so the react-hook-form binding in RuleFormModal and the existing tests still address it the same way. Only these five were deprecated. The other `bordered` props in the tree sit on QRCode, Table, Descriptions and Alert, where the prop is not deprecated, and these were the only two Space `direction` uses in the codebase. * fix(frontend): restore lint rules lost in the oxlint migration, and test the guard Addresses the review on #6262. The frontend config re-enabled only no-explicit-any and no-unused-vars and left the rest of tseslint's recommended set to oxlint's correctness category. It does not cover all of it. Confirmed by linting one probe file against both configs: docs/ (which enumerates the rules) reports all nine, frontend/ reported four. So ban-ts-comment, no-empty-object-type, no-namespace, no-require-imports and no-unsafe-function-type had silently stopped being enforced — a `// @ts-ignore` or a `namespace` block would have landed unflagged. The ten rules are now mirrored from docs/.oxlintrc.json, and src/ still passes. The #6121/#6127 guard was 57 lines of hand-written AST walking with no test. It now has one: fixtures for the three banned shapes plus an onNumber()-wrapped control, asserting the rule fires three times and that .oxlintrc.json still wires it to the right paths. Verified it fails for the right reason by making walk() enumerate nothing, which is the silent-death mode the review described — the traversal depends on Object.keys() seeing AST children as own enumerable properties. The fixtures deliberately violate the rule, so their oxlint config is named guard.oxlintrc.json rather than .oxlintrc.json: oxlint discovers nested configs by directory, which would otherwise turn the fixtures into three lint errors. The test passes it explicitly with -c. Also from the review: - lint and format now cover tools/ as well as src/, so the one piece of hand-written lint logic in the repo is no longer the least covered file in it. - lint-staged runs oxfmt before oxlint --fix. Formatting became a hard CI gate in this PR while the hook only ran the linter, so a commit could pass the hook and fail CI on formatting alone. - .oxfmtrc.json ignores public/, so the artefacts that make gen-check and make msw-worker-check byte-compare stay safe even if oxfmt is invoked without a path argument. - The MDX and generated-reference rationales that .prettierignore carried are back as comments in docs/.oxfmtrc.json — oxlint and oxfmt both accept JSONC, so relocating them was unnecessary. Not applied: the review also suggested restoring ../internal/web/dist to the ignore lists. Both tools reject `..` patterns outright ("patterns are resolved within the config file's directory"), and being outside frontend/ it is unreachable anyway.	2026-08-19 15:36:27 +02:00
PathGao	ca6955d88b	feat(ui): validate the REALITY client version range at save time (#6126) ... * feat(ui): validate the REALITY client version range at save time The impossible range from PR #6125 — a max below the effective minimum — could still be saved; the tooltip only helps a user who hovers it. Add save-time validation mirroring xray-core's parser (up to three dot-separated parts, each 0-255) on both fields, plus a cross-field check that a non-empty max is not below a non-empty min. Errors are field-level i18n keys following the REALITY target precedent, so the modal stays open and points at the offending field instead of storing a config that rejects every client. A malformed min is reported by its own field and skipped by the max comparison, so the user sees one precise error per field. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(ui): reject untrimmed client versions and revalidate max on min edits From review: the validators trimmed but the save path ships the value verbatim, and xray-core's part parser accepts no surrounding whitespace — so a green form could still save a config the core refuses to load. Reject any value that differs from its trimmed form. Also revalidate the max field after a min edit when max already shows an error, so correcting the min clears the stale cross-field message without waiting for the next submit. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com>	2026-07-28 23:04:03 +02:00
Sanaei	7f7b7e16a4	feat(xray): update xray-core to v26.7.28 and adapt panel ... Bump xtls/xray-core to 5ca6f4b7d4dc (v26.7.28) and move the three binary pins (DockerInit.sh, the Linux and Windows URLs in release.yml) in lockstep so the in-process conf.Build() validation and the child binary agree. XMC finalmask (#6487) is the breaking change. The mask's `usernames` string list is gone, replaced by a required `profiles` array whose entries each need a 3-16 character [A-Za-z0-9_] username, a parseable UUID and both Mojang texture fields; the "default to Dream when empty" fallback was removed, so an xmc mask saved by an older panel now fails to build and takes the whole config down with it rather than degrading one inbound. The textures are a signed blob only Mojang's session server can issue, so a legacy username cannot be upgraded automatically. The panel now: - rejects an incomplete xmc mask at save time (AddInbound/UpdateInbound), pointing at the specific field that is missing; - drops only the offending mask when generating the core config, for rows that never went through the form (upgrade, node sync, restored backup, direct DB edit), warning which inbound lost its obfuscation instead of leaving every inbound offline; - carries legacy usernames into profile stubs in the finalmask form so the operator keeps their player names and sees exactly what still needs filling in, and edits profiles through a list editor. No destructive DB migration: unlike the removed shadowsocks ciphers there is no valid replacement to rewrite to, and dropping the mask from stored rows would discard the operator's hostname and password for config they can still repair. The generation-time strip already prevents the startup failure. Also track the core's xmux maxConnections fallback, lowered from 6 to 3 for anti-TSPU, in the fresh-XMUX seed so a new panel config matches what the core would pick on its own. TUN gained a `desc` key and random utunN naming, but the Go validator no longer accepts TUN inbounds and the panel only renders legacy saved rows, so nothing there needs adapting. The remaining commits are REALITY log-warning wording, gRPC/XHTTP localAddr accuracy and a routing tweak, none of which change the JSON config surface. Tests cross-check the panel's profile predicate against conf.XMCProfile.Build() so a future core release that tightens or relaxes the rules fails loudly rather than silently emitting configs the core refuses to start on.	2026-07-28 13:14:06 +02:00
MHSanaei	201d4731de	fix(xhttp): stop XMUX maxConcurrency from reverting on save ... XHttpXmuxSchema defaulted maxConnections to 6 (added to mirror xray-core v26.6.27's anti-RKN client default), so load-time hydration backfilled a non-zero maxConnections onto every config whose saved xmux lacked the key. Since maxConnections and maxConcurrency are mutually exclusive on the wire, the save-time exclusivity rule then saw both fields set and silently deleted the user's maxConcurrency; the missing key came back as the '16-32' schema default on the next load, so edits appeared to never save. Revert the bare schema default to 0 and seed the anti-RKN maxConnections=6 only when XMUX is freshly toggled on (XMUX_FRESH_DEFAULTS, with maxConcurrency left blank — xray-core parses an empty range string as 0), so the two strategies never start out conflicting. The inbound and outbound XMUX forms now also clear the opposing field live as soon as the user sets one, so whichever strategy was actually typed is the one persisted. Closes #5864	2026-07-11 20:43:47 +02:00
MHSanaei	9d1a21b484	fix(ui): keep an explicit zero happy-eyeballs delay across the round trip ... Follow-up found in review: the wire normalizer still stripped tryDelayMs when it equaled 0, but with the schema default now 250 a reload rehydrates the missing field as 250 - a user who explicitly set 0 ("disabled", per the field's own placeholder) would see 250 and any subsequent save would silently enable a delay they turned off. Keep tryDelayMs on the wire unconditionally; it is the one happy-eyeballs field whose presence changes xray's behavior. Refs #5780	2026-07-05 21:17:12 +02:00
MHSanaei	579a9daaa0	fix(ui): make the Happy Eyeballs toggle produce a config xray actually enables ... Toggling Happy Eyeballs on filled the object with schema defaults, and tryDelayMs defaulted to 0. That broke the feature twice over: xray-core treats tryDelayMs=0 as happy-eyeballs-off, and the wire normalizer strips every field that equals its default, leaving an empty object it then deletes - so the switch silently flipped back off on reopen (the "disabled when Prefer IPv6 is off" symptom; prioritizeIPv6=true was the one non-default that let the object survive). Default tryDelayMs to the recommended 250ms so an enabled config survives serialization and is functional in the core. Closes #5780	2026-07-05 20:12:34 +02:00
MHSanaei	33aada0c7c	feat(xhttp): default xmux maxConnections to 6 ... xray-core v26.6.27 changed the XHTTP client xmux default to maxConnections=6 (anti-RKN). The panel previously sent maxConnections=0, which overrode that default; default XHttpXmuxSchema to 6 so new outbounds adopt it and the wire-exclusivity rule drops maxConcurrency accordingly.	2026-06-27 20:26:03 +02:00
w3struk	d01d9867e4	fix(sub): preserve non-default scMinPostsIntervalMs and use per-inbound xmux in JSON subscriptions (#5393) ... * fix(sub): preserve non-default scMinPostsIntervalMs in inbound wire payload The frontend wire normalizer unconditionally deleted scMinPostsIntervalMs from inbound configs before persisting to the database, so JSON subscriptions could never include it — even when the admin set a non-default value like "50-150". Only strip the xray-core default ("30") or empty values. The literal "30" is a known DPI fingerprint (#5141) and must still be removed, but custom tuning knobs must survive the round-trip so that buildXhttpExtra and the JSON subscription generator can propagate them to clients. Add tests for non-default preservation and empty-value stripping. * fix(sub): use per-inbound xmux instead of global subJsonMux in JSON subscriptions The JSON subscription generator always used the global subJsonMux panel setting for outbound.Mux, even when the inbound carried per-inbound xmux inside xhttpSettings. This meant XHTTP outbounds that configured their own multiplexing via xmux still got the legacy mux.cool block injected — and the inbound's own xmux was silently ignored. Now getConfig() checks whether xmux is present in the inbound's xhttpSettings. When it is, the per-inbound xmux handles multiplexing and the legacy outbound.Mux is suppressed. When xmux is absent, the global subJsonMux is used as before. The mux selection is threaded through genVless, genVnext, genServer, and genHy as an explicit parameter so each protocol handler can decide independently. Add tests: - xmux present → outbound.Mux suppressed, xmux survives streamData() - no xmux → global subJsonMux used as outbound.Mux * feat(ui): add scMinPostsIntervalMs to inbound XHTTP form The inbound XHTTP form was missing scMinPostsIntervalMs, making it impossible for admins to configure this client-only tuning knob through the panel. The field already existed in the Zod schema and outbound form, and the wire normalizer (PR #5393) now preserves non-default values for subscription propagation. Add Form.Item for scMinPostsIntervalMs in the packet-up section of the inbound XHTTP form, after scMaxEachPostBytes. Use the existing translation key and a placeholder that shows the range format without endorsing the DPI-fingerprinted default (30). Update the Zod schema comment to clarify that scMinPostsIntervalMs is now preserved on inbound for subscriptions, while uplinkChunkSize and noGRPCHeader remain outbound-only. Add two integration tests: - Non-default value (50-150) preserved through formValuesToWirePayload - Default value (30) stripped through the full pipeline * fix(ui): show packet-up fields for auto mode in inbound XHTTP form When mode is 'auto', the server accepts all three XHTTP modes including packet-up. The packet-up-specific fields (scMaxBufferedPosts, scMaxEachPostBytes, scMinPostsIntervalMs) are therefore relevant and should be configurable. Change the conditional from 'packet-up' only to 'packet-up || auto' so admins using the default 'auto' mode can configure these fields. * fix(outbound): show scMinPostsIntervalMs for auto mode, update placeholder - Show scMinPostsIntervalMs field when mode is 'auto' in addition to 'packet-up', since auto+TLS resolves to packet-up client-side - Change placeholder from '30' (DPI fingerprint) to 'e.g. 50-150' for consistency with inbound form * fix(inbound): show scMaxEachPostBytes for all modes, gate scMaxBufferedPosts behind packet-up/auto scMaxEachPostBytes is used by xray-core in every mode (both handlePacketUp and handleStreamUp validate it) and must be visible regardless of mode. scMaxBufferedPosts is only used by handlePacketUp, so it remains gated behind the packet-up/auto conditional. Also show scMinPostsIntervalMs for auto mode in outbound form and change placeholder from '30' (DPI fingerprint) to 'e.g. 50-150'. Update snapshot to reflect the new field order. * fix(inbound): correct XHTTP field visibility per xray-core source verification - scMaxEachPostBytes: move behind packet-up/auto gate (server only checks it in handlePacketUp, not handleStreamUp) - scMaxBufferedPosts: show for packet-up, stream-up, and auto (server uses uploadQueue in both handlePacketUp and handleStreamUp) - scStreamUpServerSecs: already correct (stream-up only) Verified against xray-core hub.go and dialer.go source code. --------- Co-authored-by: w3struk <w3struk@gmail.com> Co-authored-by: MHSanaei <ho3ein.sanaei@gmail.com>	2026-06-20 00:57:47 +02:00
nima1024m	cdaf5f80db	fix(inbound): strip XHTTP client-only fields from xray config, keep for subscriptions (#5349) ... Inbound XMUX and other client-side xHTTP knobs were written into bin/config.json even though xray-core's server listener ignores them. Strip them in GenXrayInboundConfig while leaving the DB row intact so buildXhttpExtra still pushes defaults to clients via share links.	2026-06-15 16:35:43 +02:00
Rouzbeh†	0766e16684	feat: implement inbound XMUX form fields (#5211) ... * feat: implement inbound XMUX form fields * fix: replace any cast to satisfy eslint * test: update xhttp form snapshot for XMUX * fix(inbound): persist xmux on save so the XMUX form actually round-trips The inbound wire normalizer unconditionally deleted xhttpSettings.xmux, so the new inbound XMUX form was stripped on save and never reached the stored config — the subscription extra blob (buildXhttpExtra) could never see it. Gate the deletion on the enableXmux toggle, mirroring the outbound adapter, and add regression tests for both on/off cases. * fix(xmux): enforce xray-core's maxConnections/maxConcurrency exclusivity xray-core's XmuxConfig rejects a config that sets both maxConnections and maxConcurrency. The panel pre-fills maxConcurrency ('16-32') whenever XMUX is enabled, so an explicit maxConnections would always collide and make xray refuse the config. Mirror core's semantics in the wire normalizer: when maxConnections is set (>0, an explicit opt-in since it defaults to 0), drop the leftover default maxConcurrency. Applies to both inbound and outbound xhttp. --------- Co-authored-by: Sanaei <ho3ein.sanaei@gmail.com>	2026-06-12 12:31:13 +02:00
Sanaei	af3c808444	fix: default hysteria tls to no utls fingerprint	2026-06-08 13:15:51 +02:00
nima1024m	6ed6f57b5c	fix(panel): normalize XHTTP/sockopt/Reality wire output and validate REALITY target (#4988) ... * fix(panel): normalize XHTTP/sockopt/Reality wire output and validate REALITY target Strip mode-specific XHTTP fields for stream-one, reset harmful sockopt defaults to 0, split server/client Reality fields on save, validate target host:port in the inbound form, and expose Happy Eyeballs for the direct freedom outbound. Co-authored-by: Cursor <cursoragent@cursor.com> * fix(panel): keep REALITY public key on the wire, guard freedom noises The REALITY server/client wire split deleted realitySettings.settings on save, but the panel stores the REALITY public key there and every share-link / subscription generator reads it back from that path (frontend inbound-link.ts, Go subService/subJsonService/subClashService). Stripping it produced empty pbk= links, breaking client connectivity after save+reload. Revert the reality normalization (drop normalizeRealityForWire and the key sets), restore the inbound REALITY form fields (uTLS, spiderX, publicKey, mldsa65Verify) while keeping the new validated target field, and restore the mldsa65Verify clear handler. Also guard freedomToWire against undefined noises/finalRules (same defensive treatment as the existing fragment guard, issue #4686) which the new freedom-outbound test surfaced as a crash. Tests now assert the public key is preserved. --------- Co-authored-by: Cursor <cursoragent@cursor.com> Co-authored-by: MHSanaei <ho3ein.sanaei@gmail.com>	2026-06-06 02:40:32 +02:00