colinhacks

@r_karotou たしかに、CSSはインジェクションはないですね。 ただ、Prepared Statement 自体はSQLの範疇でもあるので、ちゃんと使えば大丈夫じゃないかと。あとは、 colinhacks/reylo とかも生SQLとして指してる意図でした。

Am I the only one who gets sad and angry when stumbling over discussions like in zod#4939 ? If I think AI is helpful, I can ask for myself - no value provided.

TypeScript の Validation Library 6つを比較してみた！意外だったのは性能じゃなかった話 🤔 みなさん、こんにちは！ エビ 🦐 と Type Guard のことばっかり考えているフロントエンドエンジニアの @nyaomaru です！😸 TypeScript で Runtime Validation が必要になると、だいたいこんな話になるよな。 「結局、どの Library を使えばええん？」 Zod？ Valibot？ ArkType？ typia？ それとも、自分で Type Guard を書くだけで十分なんちゃう？ 僕は is-kit を開発してるので、この境界についてよく考えてる。 そこで最近、こんな疑問が出てきた。 そもそも、同じ問題を解決している Library 同士を比較できてるんやろか？ 例えば、欲しいのがこれだけなら、 if (isUser(input)) { input.name; } ほんまに Schema System まで必要なん？ でも逆に、 構造化された Validation Error 値の Transformation Parsing Schema Metadata Framework Integration が必要なら、小さな Boolean Guard だけでは足りへんこともある。 そこで今回は「どれが一番ええ Validator なん？」ではなく、ちょっと違う観点で比較してみた。 同じ User の Validation を、以下の7つの方法で実装したで。 手書きの JavaScript Guard + TypeScript の Type Predicate is-kit Runtypes Valibot Zod ArkType typia 6つの OSS と、Library を使わない手書き実装やな。 それぞれを Compile して、同じ Fixture で Test して、Browser Bundle Size を測って、簡単な Steady-state Runtime Benchmark も回した。 で、一番難しかったのは、7つを Compile することじゃなかった。 7つの Validator に、同じ意味の Validation をさせることやった。 例えば「100文字以下の String」という条件ですら、Runtime では違う意味になり得る。 ほんなら、それぞれ何ができて、何を引き換えにしているのか見てこか〜！😺 github.com/nyaomaru 🧪 今回 Validate する User まずは共通の Type から。 type User = { id: string; name: string; age: number; role: "admin" | "user"; tags: string[]; profile: { bio: string; active: boolean; }; }; Runtime で検証する Rule は以下のとおり。 id は String name は UTF-16 Code Unit で1〜100 age は18〜120の整数 role は "admin" または "user" のみ tags は String の Array profile.bio は String profile.active は Boolean Root と profile の余分な Key は拒否 値の Coercion（型変換）はしない 今回の主な Input は、JSON を Decode した普通の Data を想定してる。 ここは重要。 JavaScript には Inherited Property、Sparse Array、Symbol、Getter、Non-enumerable Property みたいな変わった値も作れるからな。 この話は後で戻ってくるで。😹 1. ✍️ 手書き Guard — Guard だけで十分なこともある まずは一番地味な方法。TypeScript の Type Predicate を付けた、手書きの JavaScript Guard や。 Validation Library は使わない。 const isRecord = (value: unknown): value is Record<string, unknown> => typeof value === "object" && value !== null && !Array.isArray(value); const hasExactKeys = ( value: Record<string, unknown>, keys: readonly string[], ): boolean => Object.keys(value).length === keys.length && keys.every((key) => Object.hasOwn(value, key)); export const isUser = (value: unknown): value is User => { if ( !isRecord(value) || !hasExactKeys(value, ["id", "name", "age", "role", "tags", "profile"]) ) { return false; } if ( !isRecord(value.profile) || !hasExactKeys(value.profile, ["bio", "active"]) ) { return false; } return ( typeof value.id === "string" && typeof value.name === "string" && value.name.length >= 1 && value.name.length <= 100 && typeof value.age === "number" && Number.isInteger(value.age) && value.age >= 18 && value.age <= 120 && (value.role === "admin" || value.role === "user") && Array.isArray(value.tags) && value.tags.every((tag) => typeof tag === "string") && typeof value.profile.bio === "string" && typeof value.profile.active === "boolean" ); }; 使う側はこんな感じ。 declare const input: unknown; if (isUser(input)) { input.name.toUpperCase(); } 一箇所だけ Narrowing したいなら、手書き Guard で十分やと思う。 Dependency も新しい抽象化もいらへん。 でも isUser、isProfile、isRole みたいな Guard がどんどん増えてきたら……。 自分だけの小さな Guard Library を保守し始めてる わけやな。😹 そこで次の選択肢が出てくる。👍 2. 🔧 is-kit — 小さな Guard を再利用したくなったら まさにここが、僕が is-kit を作った理由や。 Narrowing のたびに Schema-first の Workflow を使いたかったわけちゃう。 小さな Guard は小さいまま、きれいに Compose できるようにしたかった。 import { and, arrayOf, isBoolean, isNumber, isString, oneOfValues, predicateToRefine, safeParse, struct, } from "is-kit"; export const isName = and( isString, predicateToRefine<string>( (value) => value.length >= 1 && value.length <= 100, ), ); export const isAge = and( isNumber, predicateToRefine<number>( (value) => Number.isInteger(value) && value >= 18 && value <= 120, ), ); export const isProfile = struct( { bio: isString, active: isBoolean, }, { exact: true }, ); export const isUser = struct( { id: isString, name: isName, age: isAge, role: oneOfValues("admin", "user"), tags: arrayOf(isString), profile: isProfile, }, { exact: true }, ); export const parseUser = (input: unknown) => safeParse(isUser, input); 僕にとって大事なのは、struct() で Object を Validate できること自体じゃない。 組み合わせた部品が、普通の Guard としてそのまま使えること や。 const names = values.filter(isName); if (isAge(value)) { // value is number } すでに Predicate を中心に Code を書いているなら、これは便利やと思う。 ただし、is-kit は Full Schema Library を目指しているわけではない。 safeParse() が返すのは小さな Success / Failure の Result。Field ごとの詳細な Issue、Transformation、Schema Metadata を提供するものではない。 そうした機能や Framework Integration が必要なら、僕なら Schema Library を選ぶで。🔧 それと、Type Level で見つかった点も書いておく。 struct() と arrayOf() は Readonly な構造を Inference する。 だから Runtime の Shape は User と一致していても、readonly string[] は Mutable な string[] に Assign できない。 この違いは Cast で隠さず、Type Test でも明示してるで。🔧 3. 🏃 Runtypes — Predicate ではなく Validator Object Runtypes はもう一段違う考え方や。 単に Boolean を返す Predicate ではなく、一つの Runtime Validator Object に複数の使い方が用意されてる。 import { Array as RtArray, Boolean as RtBoolean, Literal, Number as RtNumber, Object as RtObject, String as RtString, Union, } from "runtypes"; const Name = RtString.withConstraint( (value) => (value.length >= 1 && value.length <= 100) || "name length must be 1..100", ); const Age = RtNumber.withConstraint( (value) => (Number.isInteger(value) && value >= 18 && value <= 120) || "age must be an integer in 18..120", ); export const UserSchema = RtObject({ id: RtString, name: Name, age: Age, role: Union(Literal("admin"), Literal("user")), tags: RtArray(RtString), profile: RtObject({ bio: RtString, active: RtBoolean, }).exact(), }).exact(); export const isUser = (input: unknown) => UserSchema.guard(input); export const checkUser = (input: unknown) => UserSchema.check(input); export const parseUser = (input: unknown) => UserSchema.parse(input); export const inspectUser = (input: unknown) => UserSchema.inspect(input); 普通の Predicate と違って、同じ Validator に複数の使い方がある。 guard() で Narrowing check() で失敗時に Throw parse() で Parsing inspect() で構造化された Failure Data を取得 ただし check() と parse() は同じ意味ではない。Parser の挙動によって Object の扱いが変わる場合もある。 単純な Boolean Guard とは違う Runtime の仕組みやな。🏃 4. 🤖 Valibot — Modular な API の Schema Validation Valibot からは、いよいよ Schema Library らしくなってくる。 import * as v from "valibot"; export const UserSchema = v.strictObject({ id: v.string(), name: v.pipe(v.string(), v.minLength(1), v.maxLength(100)), age: v.pipe(v.number(), v.integer(), v.minValue(18), v.maxValue(120)), role: v.picklist(["admin", "user"]), tags: v.array(v.string()), profile: v.strictObject({ bio: v.string(), active: v.boolean(), }), }); export const isUser = (input: unknown) => v.is(UserSchema, input); export const parseUser = (input: unknown) => v.safeParse(UserSchema, input); Valibot は Schema Validation、構造化された Issue、Transformation Pipeline を、Modular な Function-based API で組み合わせられる。 この設計は Tree Shaking とも相性がええ。 さらに v.is() は Type Guard として使えるで。🤖 ただし v.is() 自体は詳細な Issue を返さず、Parsing のように Transformation を適用するわけでもない。 5. 💎 Zod — Schema が Ecosystem の一部になるとき 続いて Zod。 import * as z from "zod"; export const UserSchema = z.strictObject({ id: z.string(), name: z .string() .refine( (value) => value.length >= 1 && value.length <= 100, "name must contain 1..100 UTF-16 code units", ), age: z.int().min(18).max(120), role: z.enum(["admin", "user"]), tags: z.array(z.string()), profile: z.strictObject({ bio: z.string(), active: z.boolean(), }), }); export type User = z.output<typeof UserSchema>; export const parseUser = (input: unknown) => UserSchema.safeParse(input); // This schema has no transforms, so its output type is safe for the input too. export const isUser = (input: unknown): input is User => parseUser(input).success; Zod に組み込みの is() Method はないけど、この Adapter は元の input を Narrowing できる。 今回の Schema には Transform がないからやな。 Transform を含む Schema なら、元の Input と Output の Type が違う可能性があるので、safeParse().data を Typed Value として使うほうが安全。 ここは混同したらアカンところ。 さて、Zod の魅力は User を Validate できること自体ではない。 それなら今回のどの実装でもできる。 大きいのは Schema を取り巻く Ecosystem や。 Form Integration API Tooling Schema Conversion Metadata Codec OpenAPI 関連 Tooling Framework Integration Schema が Application Infrastructure の一部になっているなら、こうした Ecosystem は強い選択理由になる。 String Length で気になったこと 今回、これは使わなかった。 z.string().min(1).max(100); なんでかって？ 今回の Contract は、 1〜100 UTF-16 Code Unit やから。 Zod の組み込み String Length Check は Unicode Code Point を数えるので、Contract に合わせるため .refine() と JavaScript の string.length を使った。 後で出てくる Emoji の Fixture で、違いがはっきりするで。😹 Bundle Size はどうなん？ 「Valibot は小さいけど、Zod は大きい」 そう単純にも言えへん。Zod には Functional で Tree-shakable な Zod Mini もある。 後半の Bundle Size は 通常版 Zod の結果で、Zod Mini の測定ではないで。 また Zod は z.compile() で Runtime の Validation Logic を最適化できるけど、今回は有効にしていない。 これは typia の Build 時の TypeScript Transform とは別の仕組みや。💎 6. 🚢 ArkType — Runtime Schema が TypeScript っぽかったら？ ArkType は Schema の書き方がかなり違う。 import { type } from "arktype"; export const UserSchema = type({ id: "string", name: "0 < string <= 100", age: "18 <= number.integer <= 120", role: "'admin' | 'user'", tags: "string[]", profile: { bio: "string", active: "boolean", }, }).onDeepUndeclaredKey("reject"); export const isUser = (input: unknown) => UserSchema.allows(input); export const parseUser = (input: unknown) => UserSchema(input); export const ArkErrors = type.errors; この比較、結構好きやねんな。 z.int().min(18).max(120); と、 "18 <= number.integer <= 120"; どっちが絶対に優れている、という話ではない。 同じ Runtime Contract を表現するための、違う書き方や。 TypeScript っぽい式が自然に読める Team なら、ArkType はかなり読みやすいと思う。 allows() は Type Guard として使えるし、Schema を直接呼ぶと Validated Output か Error Collection を取得できる。 もう一つ面白いのは、new Function が使える Environment なら Runtime で Traversal Logic を Precompile できること。 つまり ArkType も、すでに最適化された Validation Logic を作っている。 でも typia と同じ Architecture ではない。 ArkType は Runtime の Type Representation から始まる。 typia は Build 時の TypeScript Type から始まるんや。🚢 7. 🚀 typia — Build 時に Validator を生成する 今回の中で、typia は特に毛色が違う。 import typia, { type tags } from "typia"; type Utf16Name = tags.TagBase<{ kind: "utf16Name"; target: "string"; value: undefined; validate: "$input.length >= 1 && $input.length <= 100"; }>; export interface User { id: string; name: string & Utf16Name; age: number & tags.Type<"uint32"> & tags.Minimum<18> & tags.Maximum<120>; role: "admin" | "user"; tags: string[]; profile: { bio: string; active: boolean; }; } export const isUser = typia.createEquals<User>(); export const validateUser = typia.createValidateEquals<User>(); typia は TypeScript の Type と Tag を、Build 時に専用の Validation Code に変換する。Runtime Schema Object をその場で解釈する方式とは違う。🚀 ただし、Trade-off もある。 Build Integration が必要。 今回の公式 Setup は TypeScript 7 と ttsc / typia の Transform Integration を使う。 普通の tsc だけでは Transform は走らない。 僕の検証環境でも、最初の typia Build では Go の Source Plugin を Compile する必要があり、数分かかった。 この Setup Cost は Runtime Benchmark には入っていないけど、採用を決めるときには無視できへんよな。 それから、組み込みの MinLength / MaxLength は今回の UTF-16 Contract と一致しなかった。 だから name には Custom Tag を使ってる。 またしても「同じような Rule に見えるのに、実際の意味が違う」という話や。🚀 😹 えっ、String Length って同じじゃないん？ 最初に「えっ？」となったのがこの Test。 "😀".repeat(51).length; // 102 51 Unicode Code Point なのに、102 UTF-16 Code Unit になる。 今回の Contract は最大100 UTF-16 Code Unit。だから Reject されるべきや。 実際、最初から Reject したのは手書き Guard、is-kit、Runtypes、Valibot、ArkType。 一方、最初の Zod と typia の Sample は Accept した。なんでやねん！😹 組み込みの Length Constraint が Unicode Code Point を数えていたからや。 別にどっちが間違いというわけではない。 違う Runtime Contract を表している というだけ。 さらに、人間から見た「1文字」とも必ずしも一致しない。Grapheme Cluster まで考えたら Unicode はもっと面白いことになる。😹 だから、最終的には Zod を .refine() に、typia を Custom Tag に変更した。 今回の比較で、個人的に一番大きかった発見がこれ。 同じように見える Schema が、同じ Runtime Contract を表しているとは限らない。 で、結局何を比較してるん？ ここまで見ると、この7つは単なる交換可能な Library には見えへんよな。 そもそも Runtime Model が違う。 まず表で整理してみよう。 Approach Source of truth Natural success API Structured failures Transformation model Compilation / build requirement Handwritten guard Type + handwritten check Predicate Manual Manual None is-kit Composed guards Predicate / safeParse Basic valid/invalid result Guard-oriented None Runtypes Runtype object guard / check / parse Yes Parsers None Valibot Schema functions is / safeParse Yes Schema pipelines None Zod Schema objects parse / safeParse Yes Transforms / codecs No build transform; optional runtime z.compile() ArkType Runtime type expressions allows / invocation Yes Morphs No build transform; runtime precompilation when available typia TypeScript types and tags Generated predicates / validation results With validation APIs Build-generated functions Build transform required だから、これらを「上位互換への進化段階」みたいに考えるのは違うと思うようになった。 Schema Library は「より優れた Type Guard」とは限らない。 Generated Validator も「より優れた Schema」とは限らない。 問題が重なる部分はあるけど、解決している Layer が違うんやな。 ✅ 実際に何が Pass したん？ 同じ35個の JSON Fixture で7つの実装を検証した。 35 fixtures × 7 validators = 245 checks 245個、すべて Pass！ ✅ 境界値、Emoji の Length、間違った型、Missing Field、余分な Key などを確認してる。Harness では Type Narrowing、Input Mutation、Build、Bundle 後の動作も検証した。 再現してみたい人はこちら。😺 Harness、Lockfile、Fixture、Probe、Benchmark の結果は、固定 Commit の typescript-validator-comparison に公開してるで。 git clone nyaomaru/typescript-validator-comparison cd typescript-validator-comparison git checkout --detach b26350d01fd18cb77d55a95e2f3b112657f0d305 corepack pnpm install --frozen-lockfile corepack pnpm verify 今回の JSON に相当する Contract では7つの実装が一致した、という結果や。あらゆる JavaScript Value に対する完全な一致を意味するわけではないで。 🧩 もう一つの驚き。「Exact」って本当に Exact なん？ 普通の JSON に収まらない Value も Test してみた。 表に出す4つの Probe は、この Code に対応してる。 const sparseTags = { ...valid, tags: new Array(2) }; const inheritedFields = Object.create(valid); const extraSymbol = { ...valid, [Symbol("extra")]: true }; const extraUndefined = { ...valid, extra: undefined }; Repository では、このほかに Non-enumerable Property や Throw する Getter を含む、さらに9つの Probe を実行している。 この4つの結果はこんな感じ。 Probe Native is-kit Runtypes Valibot Zod ArkType typia Sparse tags array Accept Reject Accept Reject Reject Reject Accept All fields inherited Reject Reject Reject Accept Accept Accept Accept Extra symbol property Accept Accept Reject Accept Accept Reject Accept Extra key with value undefined Reject Reject Reject Reject Reject Reject Accept さらに、Test した余分な Non-enumerable Property は7つすべてで Accept された。 そして Throw する Getter を読み取るケースでは、7つとも Throw した。 どれかの Library が壊れている、という話ではない。 「Exact Object Validation」には、対象範囲の定義が必要 ということや。 手書き Guard の Object.keys() は Symbol や Non-enumerable Key を見ないし、Array.every() は Sparse Array の Hole を Skip する。 JSON Data なら合理的でも、あらゆる JavaScript Object に共通する Rule ではないんやな。😺 📦 Bundle Size さて、みんな気になる Bundle Size や！😺 Browser 向けの各 Entry は validate だけを Export している。 設定はすべて同じ esbuild の条件に揃えた。 Browser Platform ESM ES2022 Minify Tree Shaking Legal Comment を削除 Raw、gzip、Brotli の Size を測った結果がこれ。 Validator Raw bytes gzip bytes Brotli bytes handwritten guard 588 337 295 is-kit 3,421 1,530 1,423 runtypes 16,667 5,188 4,657 valibot 5,722 1,853 1,675 zod 89,888 26,212 23,331 arktype 155,549 47,603 41,956 typia 772 403 339 結果を見る前に、3つだけ注意してな。👇 Standalone Cost: 独立した Bundle の Size。既存 Application に Schema を1つ追加する Cost とは違う。 通常版 Zod: Zod Mini は測っていない。 Generated Code: typia の小さな Bundle にも生成 Code と Helper は含まれる。 それでも、Architecture の違いが表れているのは面白いな。😺 ⚡ Runtime Performance 同じ Contract で、簡単な Steady-state Benchmark も回してみた。 Case は正常な User、間違った id、間違った profile.active の3つ。 各 Library を別々の Node Process で実行し、20,000 Call の Warmup 後に、50,000 Call × 9 Sample を測定した。Schema の生成は測定 Loop の外や。 結果は 1 Call あたりの Median（ns）。括弧内は Min〜Max。 これは Microbenchmark なので、V8 の最適化や API の処理内容の違いに注意してな。 Validator Valid (ns/call) Wrong id (ns/call) Wrong profile.active (ns/call) handwritten guard 79.9 (77.3–114.1) 73.6 (72.1–84.9) 80.8 (79.0–96.3) is-kit 232.0 (225.7–257.5) 34.5 (33.1–38.9) 210.3 (203.6–218.1) runtypes 5804.0 (5425.5–6298.0) 9221.8 (8443.2–11063.2) 10101.2 (9287.6–10503.5) valibot 951.2 (425.2–1782.7) 200.2 (96.1–422.3) 1112.1 (648.4–1538.1) zod 612.6 (351.3–1203.5) 1491.6 (862.9–2824.6) 2208.5 (1592.4–4757.4) arktype 291.5 (278.1–614.4) 9.6 (6.6–17.7) 12.0 (11.3–37.6) typia 21.9 (20.5–46.1) 2.0 (1.9–6.4) 11.5 (10.8–17.2) ただし、これを 「typia がどんな状況でも最速！」 と読むのは違うで。😹 同じ小さな Object を繰り返しているので、2.0 ns のような値を実際の Application にそのまま一般化はできへん。 それでも、面白い傾向はあった。👇 🚀 typia はこの Steady-state Test で Overhead が小さかった。 🚢 ArkType は Invalid Input の処理が特に速かった。 🔧 is-kit は間違った id を早い段階で Reject した。 🏃 Runtypes は今回の Loop では比較的 Cost が高かった。 Architecture と Failure Path の両方が大事、ということやな。 🤔 ほな、結局どれを使う？ ここまで検証した結果、僕の選び方は結構シンプルになった。 やりたいこと 候補 一箇所だけ Type Check ✍️ 手書き Guard 再利用できる Guard を Compose 🔧 is-kit Rich な Validator API 🏃 Runtypes Modular な Schema Validation 🤖 Valibot Schema の Ecosystem や Integration 💎 Zod TypeScript っぽい Schema Syntax 🚢 ArkType Build 時に Type から Validator を生成 🚀 typia 万人向けの勝者はおらへん。 😺 今回一番驚いたのは、Bundle Size や Speed ではなく、7つの Validator が、ちょっとずつ違う Runtime Contract を表現し得る ということ。 だから Library を選ぶ前に考えたい。 何を Validate して、結果として何が必要なん？ 一番小さくて速いものが、その Boundary にとって一番合うとは限らへん。 みんななら、どれを使う？🤔 最後まで読んでくれてありがとう〜！🤲🦐

I Compared 6 TypeScript Validation Libraries. Here's What Surprised Me 🤔 Hoi hoi! 👋   I'm nyaomaru, a frontend engineer and OSS developer working mostly with TypeScript. When we need runtime validation in TypeScript, the conversation often turns into this 👇 > "Which library should I use?" - Zod? - Valibot? - ArkType? - typia? Or maybe, just write a type guard? I maintain is-kit, so I think about this boundary quite a lot. And recently I started wondering > Are we comparing libraries that are actually solving the same problem? For example, if all I want is this if (isUser(input)) { input.name; } do I really need a schema system? But if I want: - structured validation errors - transformations - parsing - schema metadata - framework integrations then a small boolean guard is probably not enough either. So instead of asking "Which validator is best?", I tried a different comparison. I implemented the same User validation with: - a handwritten guard with a TypeScript predicate - is-kit - Runtypes - Valibot - Zod - ArkType - typia Then I compiled, tested them against the same fixtures, measured standalone browser bundle size, and ran a small steady-state runtime benchmark. The hardest part was not making seven validators compile. It was making seven validators mean the same thing. Even “a string with at most 100 characters” can describe different runtime contracts. So, let's look at what each tool is actually buying us. 😺 !TypeScript Validation Battle --- 🧪 The User we will validate Here is the shared type. type User = { id: string; name: string; age: number; role: "admin" | "user"; tags: string[]; profile: { bio: string; active: boolean; }; }; And the runtime rules are: - id must be a string - name must contain 1–100 UTF-16 code units - age must be an integer from 18 to 120 - role must be exactly "admin" or "user" - tags must be an array of strings - profile.bio must be a string - profile.active must be a boolean - extra keys are rejected at the root and inside profile - values are not coerced For this comparison, the main input domain is ordinary JSON-decoded data. That matters because JavaScript can also give us strange things like inherited properties, sparse arrays, symbols, getters, and non-enumerable keys. We'll come back to those later. --- 1. ✍️ Handwritten Guard — Sometimes a Guard Is Enough Let's start with the boring option, a handwritten JavaScript guard with a TypeScript predicate. No validation library. const isRecord = (value: unknown): value is Record<string, unknown> => typeof value === "object" && value !== null && !Array.isArray(value); const hasExactKeys = ( value: Record<string, unknown>, keys: readonly string[], ): boolean => Object.keys(value).length === keys.length && keys.every((key) => Object.hasOwn(value, key)); export const isUser = (value: unknown): value is User => { if ( !isRecord(value) || !hasExactKeys(value, ["id", "name", "age", "role", "tags", "profile"]) ) { return false; } if ( !isRecord(value.profile) || !hasExactKeys(value.profile, ["bio", "active"]) ) { return false; } return ( typeof value.id === "string" && typeof value.name === "string" && value.name.length >= 1 && value.name.length <= 100 && typeof value.age === "number" && Number.isInteger(value.age) && value.age >= 18 && value.age <= 120 && (value.role === "admin" || value.role === "user") && Array.isArray(value.tags) && value.tags.every((tag) => typeof tag === "string") && typeof value.profile.bio === "string" && typeof value.profile.active === "boolean" ); }; And then declare const input: unknown; if (isUser(input)) { input.name.toUpperCase(); } This is still very good. For one local boundary, a handwritten type guard has a huge advantage > There is no extra model to learn. It is just JavaScript runtime checks plus a TypeScript predicate. But the cost starts to appear when your codebase grows this isUser; isProfile; isRole; isNonEmptyString; isAdultAge; isStringArray; isApiResponse; isConfig; isFeatureFlag; Now you are not writing "one guard" anymore. You are maintaining your own tiny guard library. And this is where the next option starts to make sense. 👍 --- 2. 🔧 is-kit — When Small Guards Become Reusable Building Blocks This is the problem I built is-kit around. I didn't want a schema-first workflow for every narrowing problem. I wanted small guards that stay small, but compose cleanly. import { and, arrayOf, isBoolean, isNumber, isString, oneOfValues, predicateToRefine, safeParse, struct, } from "is-kit"; export const isName = and( isString, predicateToRefine<string>( (value) => value.length >= 1 && value.length <= 100, ), ); export const isAge = and( isNumber, predicateToRefine<number>( (value) => Number.isInteger(value) && value >= 18 && value <= 120, ), ); export const isProfile = struct( { bio: isString, active: isBoolean, }, { exact: true }, ); export const isUser = struct( { id: isString, name: isName, age: isAge, role: oneOfValues("admin", "user"), tags: arrayOf(isString), profile: isProfile, }, { exact: true }, ); export const parseUser = (input: unknown) => safeParse(isUser, input); The important part is that the pieces remain normal guards const names = values.filter(isName); if (isAge(value)) { // value is number } That is useful when your codebase already thinks in terms of predicates. And this is also where I would draw the line. safeParse() gives a small success/failure result around a guard. It does not turn is-kit into: - a field-level issue system - a transformation pipeline - a schema metadata system - an OpenAPI ecosystem - a form integration layer If those are the actual requirements, I would rather use a schema library than try to make a guard toolkit become one. One type-level detail also showed up in the verification, struct() and arrayOf() infer readonly structures. So the runtime shape matches our User, but readonly string[] is not assignable to mutable string[]. That difference is real, and the type tests make it explicit instead of hiding it with a cast. 🔧 --- 3. 🏃 Runtypes — A Validator Object, Not Just a Predicate Runtypes moves one level further. Instead of just a boolean predicate, you get a runtime validator object with several ways to consume it. import { Array as RtArray, Boolean as RtBoolean, Literal, Number as RtNumber, Object as RtObject, String as RtString, Union, } from "runtypes"; const Name = RtString.withConstraint( (value) => (value.length >= 1 && value.length <= 100) || "name length must be 1..100", ); const Age = RtNumber.withConstraint( (value) => (Number.isInteger(value) && value >= 18 && value <= 120) || "age must be an integer in 18..120", ); export const UserSchema = RtObject({ id: RtString, name: Name, age: Age, role: Union(Literal("admin"), Literal("user")), tags: RtArray(RtString), profile: RtObject({ bio: RtString, active: RtBoolean, }).exact(), }).exact(); export const isUser = (input: unknown) => UserSchema.guard(input); export const checkUser = (input: unknown) => UserSchema.check(input); export const parseUser = (input: unknown) => UserSchema.parse(input); export const inspectUser = (input: unknown) => UserSchema.inspect(input); This feels different from a guard toolkit. A predicate mainly answers > Is this value a User? A Runtype can also answer that question, but the same object can: - narrow with guard - throw with check - parse with parse - expose structured failure data Also, check() and parse() should not be treated as synonyms. Runtypes supports parser behavior, and object handling can differ between validation and parsing contexts. That is exactly the kind of runtime machinery you do not have in a plain predicate. 🏃 --- 4. 🤖 Valibot — Schema Validation With a Modular API Valibot is where the comparison starts looking more "schema-like". import * as v from "valibot"; export const UserSchema = v.strictObject({ id: v.string(), name: v.pipe(v.string(), v.minLength(1), v.maxLength(100)), age: v.pipe(v.number(), v.integer(), v.minValue(18), v.maxValue(120)), role: v.picklist(["admin", "user"]), tags: v.array(v.string()), profile: v.strictObject({ bio: v.string(), active: v.boolean(), }), }); export const isUser = (input: unknown) => v.is(UserSchema, input); export const parseUser = (input: unknown) => v.safeParse(UserSchema, input); This gives us: - schema validation - type inference - structured issues - parsing APIs - transformation pipelines But the API is still function-based and modular. That is a big part of Valibot's design. Instead of every capability living as methods on large schema objects, you compose independent functions. That makes tree shaking a first-class part of the normal API. And unlike a pure schema-only mental model, Valibot also exposes v.is() as a type guard. So schema validation and ordinary TypeScript narrowing are not mutually exclusive. One caveat: v.is() is the guard path. It does not expose validation issues or apply transformations like parsing does. 🤖 --- 5. 💎 Zod — When the Schema Is Part of a Bigger Ecosystem Now Zod. import * as z from "zod"; export const UserSchema = z.strictObject({ id: z.string(), name: z .string() .refine( (value) => value.length >= 1 && value.length <= 100, "name must contain 1..100 UTF-16 code units", ), age: z.int().min(18).max(120), role: z.enum(["admin", "user"]), tags: z.array(z.string()), profile: z.strictObject({ bio: z.string(), active: z.boolean(), }), }); export type User = z.output<typeof UserSchema>; export const parseUser = (input: unknown) => UserSchema.safeParse(input); // This schema has no transforms, so its output type is safe for the input too. export const isUser = (input: unknown): input is User => parseUser(input).success; Zod does not expose a built-in is() method, but this adapter can narrow input because this schema has no transforms. With a transforming schema, safeParse().data is the safe typed value: the original input and output types may differ. Zod is not interesting because it can validate a User. All of these libraries can do that. The real value is everything around the schema: - form integrations - API tooling - schema conversion - metadata - codecs - OpenAPI-related tooling - framework integrations If your schema is already becoming part of application infrastructure, that ecosystem matters. 💎 There is one important detail in this sample though. I did not use this z.string().min(1).max(100); Why? Because our contract says > 1–100 UTF-16 code units Zod's built-in string length checks use Unicode code points, so this sample uses .refine() with JavaScript's string.length to preserve the stated UTF-16 contract. The shared emoji fixture demonstrates why below. What about bundle size? It is too easy to write > Valibot is small, Zod is large. That is not a good 2026 comparison anymore. Zod also has Zod Mini, which uses a more functional, tree-shakable API. The bundle table later in this article measures regular Zod, not Zod Mini. So it should not be read as Valibot versus the smallest possible Zod setup. Zod can also compile optimized validation logic at runtime with z.compile() and new Function. I did not enable it here. That makes this distinction more useful than the broad label “generated validation” runtime schema compilation vs build-time generation from TypeScript types That distinction becomes important when we get to typia. --- 6. 🚢 ArkType — What If the Runtime Schema Looked Like TypeScript? ArkType has a very different authoring model. import { type } from "arktype"; export const UserSchema = type({ id: "string", name: "0 < string <= 100", age: "18 <= number.integer <= 120", role: "'admin' | 'user'", tags: "string[]", profile: { bio: "string", active: "boolean", }, }).onDeepUndeclaredKey("reject"); export const isUser = (input: unknown) => UserSchema.allows(input); export const parseUser = (input: unknown) => UserSchema(input); export const ArkErrors = type.errors; I like this comparison z.int().min(18).max(120); vs "18 <= number.integer <= 120"; Neither is "better". They are different ways to express the runtime contract. If your team already thinks naturally in TypeScript-like expressions, ArkType is very readable. allows() also works as a type guard. And calling the schema directly gives you validated output or an error collection. Another interesting part: ArkType can precompile optimized traversal logic at runtime when the environment allows new Function. So ArkType is already doing specialization. 🚢 But it is still not the same architecture as typia. ArkType starts from a runtime type representation. typia starts from TypeScript types during the build. --- 7. 🚀 typia — Generate the Validator During the Build typia is the outlier in this comparison. import typia, { type tags } from "typia"; type Utf16Name = tags.TagBase<{ kind: "utf16Name"; target: "string"; value: undefined; validate: "$input.length >= 1 && $input.length <= 100"; }>; export interface User { id: string; name: string & Utf16Name; age: number & tags.Type<"uint32"> & tags.Minimum<18> & tags.Maximum<120>; role: "admin" | "user"; tags: string[]; profile: { bio: string; active: boolean; }; } export const isUser = typia.createEquals<User>(); export const validateUser = typia.createValidateEquals<User>(); This is not a runtime schema object. The source of truth is the TypeScript type plus typia's tags. Then typia's build transform turns typia.createEquals<User>(); into specialized validation code. That means there is no general runtime schema interpreter walking a User schema object. But there is a trade-off > You need build integration. The current official setup uses TypeScript 7 and ttsc / typia's transform integration. Stock tsc alone does not run the transform. In my verification workspace, the first typia build also had to compile a Go source plugin and took several minutes. That setup cost is not part of the runtime benchmark, but it is absolutely part of the adoption decision. Also, typia's built-in MinLength / MaxLength did not match our UTF-16 contract. So I used a custom tag for name. Again, same-looking validation rule, different semantics. 🚀 --- 😹 Wait, Even "String Length" Was Different? This was the first test that made me stop. "😀".repeat(51).length; // 102 JavaScript's string.length counts UTF-16 code units. So with our contract maximum = 100 UTF-16 code units this should fail. And it did fail in: - handwritten guard - is-kit - Runtypes - Valibot - ArkType But the original Zod and typia samples accepted it. Why? Because their built-in length constraints count Unicode code points instead. For this string 51 emoji = 51 code points = 102 UTF-16 code units Neither behavior is wrong. They are just different contracts. And neither one necessarily matches "what a human sees" either, because grapheme clusters make Unicode even more fun. 😹 So I changed the Zod sample to .refine() and typia to a custom tag. That was probably the most useful lesson in the whole comparison 👇 > Equivalent-looking schemas are not automatically equivalent runtime contracts. --- So What Are We Actually Comparing? At this point, these no longer look like seven interchangeable libraries. They are different runtime models. | Approach | Source of truth           | Natural success API                       | Structured failures       | Transformation model       | Compilation / build requirement                           | | --------- | -------------------------- | ------------------------------------------ | --------------------------- | -------------------------- | ---------------------------------------------------------- | | Handwritten guard | Type + handwritten check   | Predicate                                 | Manual                     | Manual                     | None                                                       | | is-kit   | Composed guards           | Predicate / safeParse                   | Basic valid/invalid result | Guard-oriented             | None                                                       | | Runtypes | Runtype object             | guard / check / parse               | Yes                         | Parsers                   | None                                                       | | Valibot   | Schema functions           | is / safeParse                         | Yes                         | Schema pipelines           | None                                                       | | Zod       | Schema objects             | parse / safeParse                     | Yes                         | Transforms / codecs       | No build transform; optional runtime z.compile()         | | ArkType   | Runtime type expressions   | allows / invocation                     | Yes                         | Morphs                     | No build transform; runtime precompilation when available | | typia     | TypeScript types and tags | Generated predicates / validation results | With validation APIs       | Build-generated functions | Build transform required                               | This is why I no longer like thinking about them as a simple upgrade ladder. A schema library is not "a better type guard". A generated validator is not "a better schema". They solve overlapping problems at different layers. --- ✅ What Actually Passed? The complete harness, lockfile, fixtures, probes, and generated result files live in typescript-validator-comparison. The article links to that immutable commit, rather than to a moving branch. To reproduce the recorded snapshot: git clone https://github.com/nyaomaru/typescript-validator-comparison.git cd typescript-validator-comparison git checkout --detach b26350d01fd18cb77d55a95e2f3b112657f0d305 corepack pnpm install --frozen-lockfile corepack pnpm verify pnpm verify runs lint, strict type checking, fixtures, bundle measurement, benchmarks, JavaScript-only probes, and report generation. The result tables below are that run's saved snapshot, reruns on another machine will naturally produce different timing numbers. I pinned the versions and ran the same fixture matrix against all seven implementations. Environment Date:       2026-10-23 Node:       24.22.1 TypeScript: 7.0.2 pnpm:       11.22.0 ttsc:       0.31.3 tsbuild:    0.28.2 Packages | Package   | Version | | --------- | -------- | | is-kit   | 1.15.3   | | runtypes | 7.0.5   | | valibot   | 1.5.0   | | zod       | 4.6.5   | | arktype   | 2.2.8   | | typia     | 15.1.0   | The shared matrix contains 35 JSON fixtures. That includes: - valid users - age boundaries - name boundaries - emoji length cases - wrong primitive types - missing fields - invalid roles - invalid array elements - extra root keys - extra nested keys - non-object roots All seven matched the expected result. 35 fixtures × 7 validators = 245 boolean checks All 245 passed. The harness also checks input mutation, richer APIs, strict TypeScript compilation, lint, builds, narrowing, and bundled output behavior. So the implementations agree for the JSON-shaped contract in this article—not necessarily for every JavaScript value. --- 🧩 One More Surprise: "Exact" Is Not Always Exact I also tested values outside the normal JSON-shaped input domain. The four probes in the table mean exactly this: const sparseTags = { ...valid, tags: new Array(2) }; const inheritedFields = Object.create(valid); const extraSymbol = { ...valid, [Symbol("extra")]: true }; const extraUndefined = { ...valid, extra: undefined }; The repository runs nine more probes, including non-enumerable properties and a throwing getter. Here is what happened for these four | Probe                             | Native | is-kit | Runtypes | Valibot | Zod     | ArkType | typia   | | --------------------------------- | ------ | ------ | -------- | -------- | ------- | -------- | ------- | | Sparse tags array               | Accept | Reject | Accept   | Reject   | Reject | Reject   | Accept | | All fields inherited             | Reject | Reject | Reject   | Accept   | Accept | Accept   | Accept | | Extra symbol property             | Accept | Accept | Reject   | Accept   | Accept | Reject   | Accept | | Extra key with value undefined | Reject | Reject | Reject   | Reject   | Reject | Reject   | Accept | All seven accepted the extra non-enumerable property I tested. All seven threw when reading a getter that throws. This does not mean one library is "correct" and the others are broken. It means > "Exact object validation" needs a scope. For example, my native guard uses Object.keys(value); That only sees enumerable string keys. And this value.tags.every(...) skips sparse array holes. That is perfectly reasonable for JSON data. It is not a universal policy for every weird object JavaScript can create. This is another reason I think validator comparisons should state the expected input domain. --- 📦 Bundle Size Now the fun table. 😺 Each browser-targeted entry exports only validate. All of them were bundled with the same esbuild settings: - browser platform - ESM - ES2022 - minification - tree shaking - legal comments removed Then I measured raw, gzip, and Brotli output. | Validator | Raw bytes | gzip bytes | Brotli bytes | | ---------- | --------: | ---------: | -----------: | | handwritten guard |       588 |        337 |          295 | | is-kit     |     3,421 |      1,530 |        1,423 | | runtypes   |    16,667 |      5,188 |        4,657 | | valibot   |     5,722 |      1,853 |        1,675 | | zod       |    89,888 |     26,212 |       23,331 | | arktype   |   155,549 |     47,603 |       41,956 | | typia     |       772 |        403 |          339 | A few important caveats. This is standalone cost If your app already ships Zod, the marginal cost of one more schema is not 26 KB gzip. This table measures isolated entry bundles. This is regular Zod Not Zod Mini. So this table does not answer > Valibot vs Zod Mini? Generated does not mean zero bytes typia's final guard bundle was only 772 bytes raw in this test. But it still shipped generated code and a uint32 helper. "Generated validator" does not mean "free validator". Still, the architectural difference is very visible here. --- ⚡ Runtime I almost did not include runtime numbers because validator benchmarks get misleading very quickly. But since the workspace already had the same contract and fixtures, I ran a small steady-state benchmark. Three cases: - valid user - wrong id - wrong nested profile.active Each library ran in a separate Node process. Each case used: - 20,000 warmup calls - 9 measured samples - 50,000 calls per sample Schemas and validators were created outside the measured loop. Results are median nanoseconds per call, with min–max in parentheses. | Validator |                  Valid |              Wrong id |   Wrong profile.active | | ---------- | ---------------------: | ----------------------: | -----------------------: | | handwritten guard |      79.9 (77.3–114.1) |       73.6 (72.1–84.9) |        80.8 (79.0–96.3) | | is-kit     | 232.0 (225.7–257.5) | 34.5 (33.1–38.9) | 210.3 (203.6–218.1) | | runtypes   | 5804.0 (5425.5–6298.0) | 9221.8 (8443.2–11063.2) | 10101.2 (9287.6–10503.5) | | valibot   |    951.2 (425.2–1782.7) |     200.2 (96.1–422.3) |   1112.1 (648.4–1538.1) | | zod       |   612.6 (351.3–1203.5) | 1491.6 (862.9–2824.6) | 2208.5 (1592.4–4757.4) | | arktype   |    291.5 (278.1–614.4) |           9.6 (6.6–17.7) |         12.0 (11.3–37.6) | | typia     |      21.9 (20.5–46.1) |           2.0 (1.9–6.4) |         11.5 (10.8–17.2) | Please do not read this as: > typia is the fastest validator. This is a microbenchmark. The same small object shapes are validated repeatedly, so V8 can optimize very aggressively. I would not interpret a 2.0 ns result as a portable "cost of validation" in a real application. The success APIs are also different: - handwritten guard uses a predicate - is-kit uses a predicate - Runtypes uses .guard() - Valibot uses is() - Zod uses safeParse(...).success - ArkType uses allows() - typia uses a generated equals guard Those operations do not all perform exactly the same work. What the benchmark _does_ show is that architecture and failure path matter. For example: - the handwritten guard pays for exact-key checks before rejecting the wrong id - ArkType's invalid paths were much cheaper than its valid path - typia's generated guard had very low steady-state overhead here - Runtypes' richer validation machinery costs more in this particular hot loop That is useful. A universal speed ranking is not. --- So... Which One Would I Use? 🤔 After doing all of this, my decision tree is actually pretty simple. Just one local narrowing check? Use a handwritten guard. if (isUser(input)) { // input is User } No dependency is a feature when the problem is small. Lots of reusable guards? This is where I use is-kit. 🔧 values.filter(isName); if (isAge(value)) { // ... } The problem is not "I need a schema". The problem is "I keep rebuilding the same predicates and composition helpers". Want a validator object? Runtypes is interesting when you like having one runtime object that can: 🏃 guard check parse inspect assert Want schema validation with a modular API? Valibot. 🤖 Especially if client bundle size and tree shaking are important parts of the design. Want schemas tied into a bigger ecosystem? Zod. 💎 That is probably its strongest reason to exist in many applications. And if bundle size is a concern, evaluate Zod Mini separately. Want the schema syntax to feel like TypeScript? ArkType. 🚢 "18 <= number.integer <= 120"; is a very different authoring experience from chained schema methods. Want TypeScript types transformed into validators during the build? typia. But I would treat the build integration as part of the decision, not a footnote. --- Final Thought These tools overlap, but they live at different layers. The hard part is not making seven validators compile. It is making seven validators mean the same thing. So before comparing package size or benchmark screenshots, ask what the boundary needs to return and what runtime machinery is worth carrying. > Use the smallest model that still represents your boundary well. Then, which one will you use? Thank you for reading! 🤲

TypeScript 7.1 Can Now Import Almost Anything. So I Made It Import C++, C, and Rust. I've been following the development of Content Mappers in TypeScript for quite a while. Partly because I'm excited about what they make possible, but also because I've been working on another TypeScript extension project that relies heavily on Volar.js. And God, that's a lot of code to maintain just to get all the language features working correctly and keep everything in sync with TypeScript. But with TypeScript 7.1, we finally have an official extension mechanism built directly into the compiler. And I think this opens up some pretty interesting possibilities. What if TypeScript could import anything? Imagine being able to write something like this: import { Rows, Columns } from "./data.csv"; import { exif } from "./photo.jpeg"; import { config } from "./config.yml"; And not just import these files as strings or any, but have TypeScript actually understand their contents. Imagine getting autocomplete for your YAML configuration, properly inferred columns from a CSV file, or type information extracted directly from another file format. No manually maintained .d.ts files. No generic declare module "*.csv" that treats every CSV file identically. Just types derived from the actual content. This is the kind of thing Content Mappers make possible. And it's not entirely theoretical. Motherload, from Colin McDonnell, is already exploring typed imports for several formats. Same for his another work - Reylo, it also utilizes the same approach. But how does this actually work? How TypeScript 7.1 Content Mappers work Until now, TypeScript tooling has mostly been built around TypeScript and JavaScript files. Frameworks like Vue, Svelte, and Astro needed additional tooling to make TypeScript understand code embedded inside their custom file formats. That's where projects like Volar.js came in. Volar made it possible to provide TypeScript language features inside non-TypeScript files, including autocomplete, diagnostics, go-to-definition, and references. However, integrating this with TypeScript's compiler and language server wasn't exactly straightforward. TypeScript 7.1 introduces Content Mappers as a first-class extension point. The idea is surprisingly simple: 1. Register a Content Mapper for one or more file extensions. 2. When TypeScript encounters a matching file, it asks the mapper to process it. 3. The mapper produces a virtual TypeScript representation of the file. 4. TypeScript uses that representation for type checking and language services. But here's the really interesting part. The mapper can also provide source mappings between the virtual TypeScript code and the original file. So TypeScript doesn't just understand the generated declarations. It can connect them back to their original source locations. That means things like hover information, diagnostics, go-to-definition, references, and rename can work across file formats. For example, imagine a Content Mapper that processes this C++ function: // math.cpp int add(int a, int b) { return a + b; } It could expose the following virtual TypeScript declaration: export declare function add( a: number, b: number ): number; Now TypeScript knows the function exists, what arguments it accepts, and what it returns. And because the mapper knows where add, a, and b came from in the original C++ source, editor navigation can work across the language boundary. Pretty cool, right? Of course, Content Mappers don't automatically make arbitrary files executable. They solve the TypeScript understanding and tooling side of the problem. Actually running those imports is still the responsibility of the runtime or another loader. And that's where I started thinking about another problem. What about native code? I'm currently building a small inference engine, and some of its functionality lives in C++. One of my biggest headaches has been integrating that native code with Node.js. Normally, if you want to call a C++ function from Node.js, you need to create native bindings using Node-API (N-API). It works, but it also means writing extra glue code, compiling addons, keeping TypeScript declarations in sync, and dealing with the build process. There are libraries like Koffi that make native interoperability easier, and they're definitely interesting. But I wanted something slightly different. I wanted the native source itself to be the source of truth. What if TypeScript could read C++ function signatures directly? What if I could get IntelliSense, type checking, and go-to-definition without maintaining another layer of definitions? And what if the native bindings could be generated and compiled automatically? Essentially: What if importing a C++ function felt exactly like importing another TypeScript function? Well, I decided to try building it. Introducing ts-polyglot ts-polyglot is an experimental project that lets you import functions from C, C++, and Rust source files directly into TypeScript, with inferred types and native execution through Node.js. Here's what that looks like. First, a regular C function: // add.c int add(int a, int b) { return a + b; } A C++ function: // greet.cpp #include <string> std::string greet(std::string name) { return "Hello, " + name; } And a Rust function: // square.rs pub fn square(n: i32) -> i32 { n * n } Now, from TypeScript: import { add } from "./add.c"; import { greet } from "./greet.cpp"; import { square } from "./square.rs"; console.log(add(2, 3)); // 5 console.log(greet("TypeScript")); // Hello, TypeScript console.log(square(6)); // 36 That's it. No handwritten N-API wrappers. No manually maintained TypeScript declarations. No separate native build command. And these aren't untyped calls. TypeScript understands the imported signatures: add(1, 2); // ✅ add("hello", 2); // ❌ TypeScript error square(5); // ✅ square(true); // ❌ TypeScript error You also get IntelliSense, hover information, and navigation to the original native source. But functions are only part of the story. We can import native structs too One thing I really wanted was to avoid manually recreating C++ data structures in TypeScript. Consider this simple C++ file: // geometry.cpp struct Point { double x; double y; }; double distanceSquared(Point point) { return point.x * point.x + point.y * point.y; } With ts-polyglot, we can import both the function and the native struct type: import { distanceSquared, type Point } from "./geometry.cpp"; const point: Point = { x: 3, y: 4 }; console.log(distanceSquared(point)); // 25 TypeScript understands Point automatically. Under the hood, the Content Mapper generates the equivalent of: export interface Point { x: number; y: number; } export declare function distanceSquared( point: Point ): number; But you never have to write or maintain that interface yourself. Change the native struct, and the generated TypeScript representation changes with it. This also works with supported nested structs and array fields. And importantly, Point isn't just a type-checking trick. When you call distanceSquared(point), ts-polyglot converts the JavaScript object into the native struct expected by C++. Which brings us to the more interesting implementation details. How do we discover which native functions can be imported? This was one of the first interesting challenges. C, C++, and Rust have very different syntax, and simply searching for function definitions with regular expressions obviously isn't going to work. We need to understand the structure of the source code. For that, ts-polyglot uses Tree-sitter. Tree-sitter is a parser system that can generate syntax trees for many programming languages. We use its C, C++, and Rust grammars to parse native source files and find declarations that we can expose to TypeScript. The process looks roughly like this: 1. Parse the native source When ts-polyglot encounters a native file, it passes the source through the appropriate Tree-sitter parser. Tree-sitter gives us a syntax tree containing function definitions, parameter declarations, return types, structs, and other language constructs. For example: struct Point { double x; double y; }; double distanceSquared(Point point) { return point.x * point.x + point.y * point.y; } From this, we can extract information equivalent to: Struct: Point x: double y: double Function: distanceSquared Parameters: point: Point Returns: double The important thing is that we're reading the actual native source, not a separate declaration file. 2. Find supported functions Next, we traverse the syntax tree looking for functions that can be imported. It's not limited to simple top-level functions. For example, ts-polyglot can discover supported C++ functions inside namespaces: namespace math { double square(double x) { return x * x; } } It also handles functions inside extern "C" blocks and public functions inside Rust modules. But finding a function isn't enough. We also need to determine whether its parameters and return type can actually cross the JavaScript/native boundary. A function that accepts a double is relatively straightforward. A function that accepts an arbitrary pointer, a complicated template, or a mutable reference is a very different problem. So before exposing a function, we inspect its signature and check whether every parameter and the return value have a supported type mapping. If the function contains unsupported types, we skip it rather than generating a TypeScript declaration that we can't actually support at runtime. This means you can have a native source file containing many different functions, and ts-polyglot will expose the subset it knows how to handle. 3. Resolve native types into TypeScript types Once we know a function can be imported, we generate its TypeScript signature. For example: bool isPositive(double value); Becomes: export declare function isPositive( value: number ): boolean; For structs, we inspect the fields and recursively map their types too. This is where things become more complicated, because native types don't always have a direct JavaScript equivalent. And that leads to the next big topic. Type mapping: C++ types aren't JavaScript types TypeScript has number, string, boolean, bigint, arrays, objects, and a few other useful abstractions. C, C++, and Rust have much richer and sometimes very different type systems. So we need explicit rules for translating native types into TypeScript types. Here's a simplified overview of what ts-polyglot currently supports: | Native type | TypeScript type | |---|---| | int, int32_t, Rust i32 | number | | float, double, Rust f64 | number | | bool | boolean | | std::string, Rust String | string | | int64_t, Rust i64 | bigint for results | | struct Point | interface Point | | std::vector<double>, Vec<f64> | number[] | | Unsigned byte arrays | Uint8Array | | Fixed-size arrays | TypeScript tuples | There are some important details here. For example, 64-bit integers are represented as bigint for return values and struct fields, while parameters can accept number | bigint where supported. Array parameters are typed as readonly arrays, while returned arrays are mutable. And some native types have no safe mapping yet. You can find the full table of supported mappings here: **ts-polyglot.dev But generating TypeScript types is only half of the problem. At runtime, we also need to convert values in both directions. Type marshaling: getting values across the native boundary This is probably one of the trickiest parts of native interoperability. When TypeScript calls a C++ function, JavaScript values can't simply be passed directly into native code. They have to be converted into their corresponding native representations. This process is called type marshaling. Let's go back to our Point example: const point: Point = { x: 3, y: 4 }; distanceSquared(point); From the TypeScript side, this is just a plain JavaScript object. But our C++ function expects a native Point struct. So the generated Node-API binding needs to do something conceptually like this: 1. Receive the JavaScript object. 2. Verify that it has the expected properties. 3. Read x and y and validate their types. 4. Convert both values into native double values. 5. Construct a native Point struct. 6. Call the actual C++ function. 7. Convert the returned double back into a JavaScript number. And we do the opposite when a native function returns a struct. For example: Point createPoint(double x, double y) { return { x, y }; } From TypeScript: import { createPoint, type Point } from "./geometry.cpp"; const point: Point = createPoint(10, 20); // { x: 10, y: 20 } The generated binding reads the native struct's fields and creates a new JavaScript object. No manually written conversion code. The same principle applies to supported strings, arrays, nested structs, and other types. There are some important safety details too. Conversions are checked at runtime. If you pass a string to a function that expects an integer, the generated binding throws a TypeError. If you pass a number outside the native integer's supported range, it throws a RangeError. Arrays and structs cross the boundary by value, with their contents copied. JavaScript objects aren't simply reinterpreted as native memory. This is important because JavaScript and native code have very different memory models and ownership rules. We want an import to feel like a normal TypeScript function call without silently introducing unsafe conversions. Some mappings are smarter than simple type replacement One example I particularly like is C arrays. Consider: double mean(const double values[], size_t length) { double total = 0; for (size_t i = 0; i < length; i++) { total += values[i]; } return length ? total / length : 0; } Normally, you'd need to pass both the array and its length. But ts-polyglot can recognize supported C array-and-length parameter patterns. So the exposed TypeScript signature becomes: export declare function mean( values: readonly number[] ): number; And you can call it like this: mean([10, 20, 30]); // 20 The generated binding takes care of calculating and passing the length. It's a small example, but it demonstrates that type mapping doesn't have to be just a one-to-one translation of native types. We can expose a more natural TypeScript API while preserving the original native function. From source file to working native import Now we have two important pieces: - Function discovery and type mapping, which tell TypeScript what functions exist and how to use them. - Type marshaling, which tells the runtime how to safely call those functions. Here's how ts-polyglot connects everything. At development time: the Content Mapper When TypeScript encounters: import { distanceSquared, type Point } from "./geometry.cpp"; Our Content Mapper uses Tree-sitter to parse the C++ file, discover supported functions and structs, and generate their virtual TypeScript declarations. It also returns source mappings so TypeScript can associate symbols in those declarations with their original positions in the C++ file. Nothing needs to be compiled at this stage. TypeScript just gets the information it needs for type checking and editor features. At runtime: the Node.js import hook When Node.js encounters the same import, a different part of ts-polyglot takes over. The runtime hook: 1. Parses the native source using the same signature discovery implementation. 2. Generates Node-API bindings for the supported functions. 3. Generates the necessary type marshaling code. 4. Compiles the native code and generated bindings into a .node addon. 5. Loads the addon and exposes its functions as JavaScript exports. For Rust, the build process also involves compiling the Rust code into a static library and linking it with the generated addon. The resulting builds are cached, so subsequent imports of unchanged source files don't need to compile everything again. And there's an important detail here: Both the Content Mapper and runtime use the same Tree-sitter-based signature parser. So the types TypeScript checks are derived from the same native signatures that the runtime uses when generating bindings. This is especially useful because otherwise we'd effectively be maintaining two different interpretations of the same native code. The goal is to have a single source of truth: the native source file itself. Try it yourself The easiest way to create a sample project is: npm create ts-polyglot This scaffolds a project with C, C++, and Rust examples. For an existing project, install: npm install ts-polyglot npm install -D typescript@7.1.0-beta Then register the Content Mapper in tsconfig.json: { "compilerOptions": { "module": "nodenext", "strict": true, "noEmit": true }, "contentMappers": [ { "package": "ts-polyglot", "extensions": [".c", ".cpp", ".rs"] } ] } Type-check your project: npx tsc --runExternalCode The --runExternalCode flag is required because Content Mappers are external executable programs. And run your TypeScript file with the native import hook: node --import ts-polyglot/register main.ts You'll need Node.js 22.18+, a native C/C++ compiler, and rustc if you're importing Rust. For VS Code, use the TypeScript (Native Preview) extension, select your workspace's TypeScript 7.1 version, and enable the mapper in a trusted workspace. It's still early This is very much an experimental project. There are lots of interesting problems we haven't solved yet. Native interoperability gets complicated quickly, especially when pointers, ownership, lifetimes, mutable references, callbacks, and more complicated C++ and Rust constructs enter the picture. At the moment, ts-polyglot focuses on supported functions with well-defined mappings for numbers, booleans, strings, plain structs, and arrays. Things like arbitrary pointers, mutable out-parameters, enums, function pointers, and various templates and generics aren't supported yet. Tree-sitter also isn't a full C++ compiler. It doesn't expand macros or perform complete semantic analysis, so there are limits to what we can discover directly from the source. And TypeScript 7.1's Content Mapper protocol is still in beta, so some integration details may change. But that's part of the experiment. How much native binding boilerplate can we eliminate if TypeScript understands the source directly and the runtime can generate the bridge automatically? Why I think Content Mappers matter What excites me most about TypeScript 7.1 isn't just support for another file extension. It's the possibility of making TypeScript's type system and development tooling available to entirely different languages and file formats through a supported extension mechanism. Today we're talking about Vue components, CSV files, YAML configurations, and native functions. But the same concept could be applied to many other kinds of source files and domain-specific languages. We can start treating these files as first-class participants in a TypeScript project instead of maintaining separate declarations or building completely separate language tooling around them. And with an appropriate runtime integration, those imports can become executable too. For me, ts-polyglot is one experiment in that direction. It's still early, and there's plenty of work ahead, but I think there's something really interesting here. If you've worked with TypeScript language tooling, Volar, Node-API, native interoperability, Tree-sitter, or Content Mappers, I'd love to hear what you think. And if you want to try it or explore the implementation: GitHub: mykhailen/ts-polyglot Website: ts-polyglot.dev Supported types: ts-polyglot.dev TypeScript 7.1 announcement: devblogs.microsoft.com Feedback, ideas, and contributions are welcome!

1,391 Tags Later, 931 Still Describe One Post Each On 4 June I closed two doors at once. I pulled tag pages out of the sitemap — thin listings were inflating sixty per cent of it and eating crawl budget. The same day, for the same reason, I put a limit on the production side too: a canonical vocabulary of 45 tags and a cap of five tags per post. The commit message says exactly that: "restrict AI tag generation to a canonical ~46-tag vocabulary." It worked. Two hundred posts shipped in July and added exactly one new tag to the vocabulary. Then in September the tag count started climbing again, and it took me four months to notice. Today I sat down and counted: 1,370 Turkish posts, 1,391 distinct tags. There are more tags than there are posts. The inventory first Numbers from today's main tree, drafts excluded. The live feed.json gives the same — I counted both separately: | Measurement | Value | |---|---| | Turkish posts | 1,370 | | Distinct tags | 1,391 | | Total tag usages | 5,831 | | Tags per post | mean 4.26 · median 5 | | Tags appearing on exactly one post | 931 (66.9% of distinct) | | Appearing on at most two posts | 1,112 (79.9%) | | Share of the 15 most frequent tags | 1,809 usages = 31.0% | The head of the distribution is healthy: yazilim on 245 posts, operations 148, security 143, kariyer 141, linux 140. Fifteen tags carry a third of all usage. The problem isn't at the head; it's in the tail. I also counted where the tail came from: of the 931 single-post tags, 708 sit on posts published before 4 June and 223 after. So the vocabulary I installed that day genuinely held. The problem is the legacy stock — and the fact that the gate stopped working four months later. I didn't start deleting at this point. It felt more honest to ask something else first: who reads this field? Because calling something useless assumes someone was looking at it. Who reads a tag? I found eight places in the code that consume tags. I measured each one separately, because "tags don't do anything" is just a feeling until you check. Two of the results did not confirm what I expected. !Diagram Related posts. The scoring is simple: same category +3, each shared tag +1, top three win. I have to be honest here: taken as a whole, tags work. In 1,358 of 1,370 posts at least one candidate rises above the category-only score thanks to a tag. In only 12 posts does the top score stay at 3 — and there the selection is decided by array order, because hundreds of candidates are tied. Throwing the field away would be wrong. But by definition, a tag that lives on one post can never enter this scoring; it has nobody to share with. The tag page. I wrote this part up last week from the Search Console side, so I'll keep it short: the page ships noindex,follow, it left the sitemap on 4 June, and robots.txt closed it on 6 June. One detail from that post applies here too — and it demolishes what I'd been assuming was three layers of protection: per Google's own documentation, for noindex to work the page must not be blocked in robots.txt. A crawler that can't fetch the page never reads the noindex line. The second rule silences the first. The practical result: a tag page is neither in the sitemap nor crawlable, which leaves the human click as its only real visitor. And when you open the page of a tag that lives on one post, what do you see? A heading saying "1 post", and below it a single card: the post you just left. 931 times. A smaller finding: the card component prints only the first three tags, so 2,102 tag usages (36%) appear on no card at all. And tag links are generated without a trailing slash in four places (under the post, the homepage tag cloud, the blog listing); asking for /tags/olcum earns you a 301 to /tags/olcum/. Only the card component writes it correctly. meta keywords and schema.org. Both are still in the live HTML: <meta name="keywords" content="yazilim-kariyeri, dokumantasyon, olcum, git, surec"> and the same array inside the JSON-LD. Google's documentation on supported meta tags isn't even polite about it: the keywords tag has "no effect on indexing and ranking at all." On the structured-data side, the properties they list for Article/BlogPosting are author, dateModified, datePublished, headline and image — keywords isn't there. Harmless; but the story I'd told myself — "I write tags for SEO" — has no ground under it. Social hashtags. Here there are real consumers, two of them: the Bluesky and LinkedIn code each turn the first five tags into hashtags. 809 single-post tags fall inside that window and 804 sit on posts that were actually shared, so they went out. A hashtag's job is to take you into a feed; a hashtag with one post is a room with a door and nothing behind it. Search. The search text is assembled from title + tags + description + body. A tag only contributes something new if it isn't already in the prose — and "already there" depends on your matching rule: under strict substring matching, 567 of the 931 are present in their own post's text; allowing Turkish suffixes and separator differences, 677. So somewhere between a quarter and a third of the tail genuinely adds a new searchable word — things like invisible workload or customer trust. That's a more honest sentence than "none of it contributes." RSS, JSON Feed and llms-full.txt. I saved the real surprise for last, because before measuring I hadn't even counted these three. All of them emit every tag of every post, with no truncation: the <category> lines in RSS, the tags array in feed.json, the - Tags: line in llms-full.txt. The tail that the card hides and the hashtag window cuts at five is in full circulation here. And llms-full.txt is the very file my robots.txt policy deliberately invites AI assistants to read. So the widest consumer of the field I'd written off as unread turned out to be in the place I never looked. When the gate stopped working New tags by publication month — and I'm giving the table from the start, because the real story isn't where I'd cut it: | Month | Posts | New tags | Per post | |---|---|---|---| | 2026-04 | 368 | 602 | 1.64 | | 2026-05 | 274 | 422 | 1.54 | | 2026-06 | 232 | 51 | 0.22 | | 2026-07 | 200 | 1 | 0.01 | | 2026-08 | 97 | 49 | 0.51 | | 2026-09 | 96 | 140 | 1.46 | | 2026-10 | 71 | 70 | 0.99 | Had I started the table at June, I'd have had a dramatic "September explosion" on my hands. Add the April and May rows and the story changes: September isn't an explosion, it's a return to the pre-4-June baseline. So the question isn't "what happened in September?" but "why did the gate I installed in June stop working?" The answer is mechanical. The canonical vocabulary and the five-tag cap live inside the script that generates posts. On 3 September the topic queue ran dry — I wrote about that separately, because it broke my category rotation the same day — and posts started coming out of a different path that writes the file directly. That path never calls the old script, so it walks straight past the vocabulary and the cap. There are 14 posts carrying nine tags, and all of them are dated 19–28 September: by then the ceiling was already gone. I installed that gate, and I didn't remove it. I just installed it inside the corridor — and when the corridor changed, the gate went with it. The root cause sits one line away So why did nothing catch it? Because the validation isn't in the schema. Inside src/lib/blog-frontmatter-schema.mjs, two neighbouring lines read: category: z.enum(BLOG_CATEGORIES), // closed: technology, tutorials, career, life tags: z.array(z.string()).min(1), // at least one — no ceiling, no vocabulary I locked category to four values. For tags I never wrote anything beyond "there should be at least one." Because the vocabulary decision lived in the generator rather than the schema, this file — which inspects every post on the publishing path — waved 1,391 distinct values through without complaint. I'd seen a similar pattern when I tested my own instruction files against the code: the place nobody audits is the place that quietly drifts. The difference this time: the audit existed, it was just in the wrong layer. Same concept, two separate tags There's no normalisation either. Collapsing case, hyphen, space and Turkish-character differences, 180 clusters are represented by more than one spelling, covering 386 tags. (Drop the Turkish folding and you're left with 156 clusters / 333 tags — that fold is exactly what separates yazilim from yazılım.) The expensive ones: - devops on 124 posts · DevOps on 15 - sistem-mimarisi 123 · sistem mimarisi 5 · Sistem Mimarisi 1 - ai 74 · AI 21 - indie-hacker 95 · indie hacker 10 The tag query uses exact matching (tags.includes(tag)), so these really are different things. I tried it live: /tags/DevOps/ and /tags/devops/ both return 200 and show two separate lists. In the related-posts score those two posts behave as though they share nothing. The hashtag formatter then carries the same split somewhere else: devops becomes #Devops while DevOps becomes #DevOps, yet sistem-mimarisi and sistem mimarisi both collapse into #SistemMimarisi. There's a bilingual duplication on top: kariyer 141 / career 82, security 143 / guvenlik 51, rehber 118 / tutorial 3. Which one is correct is debatable; that using both is wrong isn't. My own note misled me Into the 11 May commit where I moved tag pages to SSR, I wrote this: > Prerendering tag pages per unique tag was producing ~100 pages. In the same commit message I counted posts precisely: "985+ posts x 2 languages = ~1970 pages." I counted one field and estimated its neighbour. I checked out that commit's tree and counted: 910 Turkish + 915 English = 1,825 tag pages. My estimate was off by a factor of eighteen. The fix still worked. But because of that "~100 pages" note I remembered the problem as a small one for months — until three and a half weeks later, on 4 June, I measured the same thing again and wrote the real number into the code. The rounded figure kept feeding the memory even while the measured one sat in a neighbouring file. One more note: in my post on 20 October I wrote "1,261 distinct Turkish tags." Counting today from both the git tree and the live feed.json gives 1,391, and the tree on that date held 1,375. A gap that size can't close in six days, so I'll redo that measurement. The number in this post is the correct one. Four questions I now ask before adding a field For any metadata field — frontmatter, database column, tag, it doesn't matter: 1. Can I name its consumers? I thought there were five; there are eight, and I'd never counted the three widest. 2. Is the vocabulary closed? If not, why not — does it genuinely need infinite variety, or was I avoiding a decision? 3. Which layer does the validation live in? My gate was inside a generation script, not beside the schema. The path changed and the gate went with it, and the schema felt nothing. Put the rule next to whatever records the data, not next to whatever produces it. 4. Does the field leave the building? Even if I close the vocabulary today, the RSS history, the hashtags already posted and the crawlers that have fetched llms-full.txt are out of my hands. Metadata doesn't come back once it has escaped. I also left myself two cheap numbers: the single-use ratio (66.9% here) and the share of the fifteen most frequent values (31.0%). If both climb at once, the vocabulary is coming apart. What I'm going to do Order matters, because clearing stock doesn't fix a mechanism. First I'll move the validation into the schema (an approved list plus lowercase normalisation), so that every path writes through the same gate. Then I'll merge the 180 spelling variants. Pruning the tail comes last — and the safety net for that is already in place: a tag address with no posts 301s to /blog/, so I can delete without creating dead links. I'm not planning to remove tag pages altogether: the listing for a tag like olcum, with 62 posts, is a genuinely useful page. What needs removing isn't the page, it's the tail that makes the page meaningless. The real lesson: I started writing this as "I kept filling a field nobody reads," and the measurement stopped me twice. I had closed the gate — but inside the corridor. And the widest reader of the supposedly unread field turned out to be three machine-facing files I had never looked at. Filling a field doesn't prove it's read; assuming it isn't read doesn't prove that either. Both are things you measure. One small note: this post's own tags were picked from the existing vocabulary. All five have been used before; I didn't add a new one. Official Sources - Meta tags and attributes that Google supports — where it states the keywords meta tag has no effect on indexing or ranking. - Article (Article, NewsArticle, BlogPosting) structured data — the properties Google uses for Article; keywords isn't among them. - Large site owner's guide to managing your crawl budget — how low-value/duplicate URLs affect crawl budget, and why noindex is the wrong tool for crawl management. - schema.org: keywords — the property's definition and how multiple values are supplied. - Zod — schema validation; the difference between a closed value set with z.enum and a free list with z.array(z.string()).

Zod maintainer refuses v3 CVE backport because advisory is agent-written

colinhacks/reylo — コード生成ゼロで.sqlファイルをTypeScriptに直接importできるRust製ツール！ ・codegenなしでSQLから直接型を推論。自動生成ファイルや監視プロセスの管理が不要に ・Rust製で高速。TS 7.1のcontent mappersを活用しPostgresやSQLite等のSQLをそのまま型安全化 ・SQL直書き派のTS開発で、スキーマ同期漏れや型不整合による障害を根絶できます #TypeScript #Rust

10.7M Views 24 Din Mein: Seedha X Se 5 Viral GitHub Launches #Shorts Top 5 trending GitHub repos, Hindi mein - har number aaj check kiya gaya hai. Is week ke top trending repos, 356k+ stars combined: 1. NVIDIA/OpenShell (18k stars) - OpenShell is the safe, private runtime for autonomous AI agents. 2. reason-machines/reason-network (1k stars) - Reason Network: your team's coding agents, talking to each other. The engine behind `reason network`. 3. firecrawl/firecrawl (194k stars) - Supercharge your AI agents with data from the web and beyond. Building the library for superintelligence. 🔥 4. colinhacks/reylo (655 stars) - Import .sql files into TypeScript with full type inference and zero codegen. 5. Shubhamsaboo/awesome-llm-apps (143k stars) - 100+ AI Agents, Agent Skills and RAG Apps - Free and Open Source. Repo links: NVIDIA/OpenShell reason-machines/reason-network firecrawl/firecrawl colinhacks/reylo Shubhamsaboo/awesome-llm-apps Comment karo "VIRAL" - saare links DM mein bhej dunga. Kisi dev dost ko bhejo jise ye chahiye. Save karlo, baad mein kaam aayega. Naman AI - AI aur dev tools, Hindi mein. Har din naya repo, har number verified. #Shorts #GitHub #AI #OpenSource #TechHindi [github trending repos, best github repositories 2026, top 5 github repos, open source projects for beginners, ai coding agents, github stars] [coding in hindi, tech shorts hindi, programming for beginners, developer tools 2026, ai tools for developers, learn coding free] [bn] ২৪ দিনে ১০.৭ মিলিয়ন ভিউ: সরাসরি X থেকে ৫টি ভাইরাল গিটহাব লঞ্চ #Shorts হিন্দিতে শীর্ষ ৫টি ট্রেন্ডিং গিটহাব রিপো - প্রতিটি নম্বর আজ চেক করা হয়েছে। এই সপ্তাহের শীর্ষ ট্রেন্ডিং রিপো, সম্মিলিতভাবে ৩৫৬ হাজারেরও বেশি স্টার: ১. NVIDIA/OpenShell (১৮ হাজার স্টার) - OpenShell হলো স্বয়ংক্রিয় AI এজেন্টদের জন্য একটি নিরাপদ, প্রাইভেট রানটাইম। ২. reason-machines/reason-network (১ হাজার স্টার) - Reason Network: আপনার দলের কোডিং এজেন্ট, যারা একে অপরের সাথে কথা বলে। `reason network`-এর পেছনের ইঞ্জিন। ৩. firecrawl/firecrawl (১৯৪ হাজার স্টার) - ওয়েব এবং অন্যান্য উৎস থেকে পাওয়া ডেটা দিয়ে আপনার AI এজেন্টদের সুপারচার্জ করুন। সুপার ইন্টেলিজেন্সের জন্য লাইব্রেরি তৈরি করা হচ্ছে। 🔥 ৪. colinhacks/reylo (৬৫৫ স্টার) - সম্পূর্ণ টাইপ ইনফারেন্স এবং জিরো কোডজেন সহ TypeScript-এ .sql ফাইল ইম্পোর্ট করুন। 5. Shubhamsaboo/awesome-llm-apps (143k তারকা) - 100+ AI এজেন্ট, এজেন্ট দক্ষতা এবং RAG অ্যাপস - বিনামূল্যে এবং ওপেন সোর্স। রেপো লিঙ্ক: NVIDIA/OpenShell reason-machines/reason-network firecrawl/firecrawl colinhacks/reylo Shubhamsaboo/awesome-llm-apps মন্তব্য করুন "ভাইরাল" - সারা লিঙ্ক ডিএম মে ভেজ দুঙ্গা। কিসি দেব দোস্ত কো ভেজো জিসে ইয়ে চাহিয়ে। করলো বাঁচাও, বাদ মে কাম আয়েগা। নমন এআই - এআই অর দেব টুল, হিন্দি মে। হার দিন নয়া রেপো, হার নম্বর যাচাই করা হয়েছে। #শর্টস #গিটহাব #এআই #ওপেনসোর্স #টেকহিন্দি [গিটহাব ট্রেন্ডিং রিপো, সেরা গিটহাব রিপোজিটরি ২০২৬, সেরা ৫টি গিটহাব রিপো, নতুনদের জন্য ওপেন সোর্স প্রজেক্ট, এআই কোডিং এজেন্ট, গিটহাব স্টারস] [হিন্দিতে কোডিং, হিন্দি টেক শর্টস, নতুনদের জন্য প্রোগ্রামিং, ডেভেলপার টুলস ২০২৬, ডেভেলপারদের জন্য এআই টুলস, বিনামূল্যে কোডিং শিখুন]

GitHub Trending Weekly #55: owly, ai-job-search, tsrs, dev-null.sh, laya, reylo, openterminal, onkey This is GitHub Trending Weekly #55. 35 trending open-source projects on GitHub right now. Paid channel subscription: youtube.com Text version link: githubawesome.com 00:00 - Introduction 00:11 - owly t4t5/owly 00:38 - ai-job-search ai-job-search-dev/ai-job-search 01:03 - tsrs oxc-project/tsrs 01:29 - new-term-radar zhuyansen/new-term-radar 01:52 - security-audit-skill cloudflare/security-audit-skill 02:18 - dev-null.sh dev-null-sh/dev-null.sh 02:43 - laya NandhaKishorM/laya 03:10 - 3d-model-anything wesbos/3d-model-anything 03:33 - rossark-motion-skill rossark0/rossark-motion-skill 04:02 - reylo colinhacks/reylo 04:29 - openterminal spovalova/openterminal 04:55 - hatchzip xevrion/hatchzip 05:23 - dquickts stencil-hq/dquickts 05:47 - ming-voice JMS1717/ming-voice 06:14 - onkey dsmurrell/onkey 06:41 - Sumi.css vladocar/Sumi.css 07:07 - rl-env-use browser-use/rl-env-use 07:35 - img2interior img2threejs/plugin-interior 08:02 - Rubix-lang tek-sys-hub/Rubix-lang 08:28 - motion2code lovisdotio/motion2code 08:54 - omnara omnara-ai/omnara 09:20 - ELYTerminal ELY-Open-Source/ELYTerminal 09:44 - prompt2rig blendi-remade/prompt2rig 10:08 - video-short petergyang/video-short 10:34 - penmentor AbdullahAlhariri/penmentor 11:02 - rec recursive-oss/rec 11:30 - BitKindle tombkeeper/BitKindle 11:55 - opal xingjian-bai/opal 12:22 - Bursar Samsara-1999/Bursar 12:47 - OpenVLHarness uclanlp/OpenVLHarness 13:10 - video-editor-skills appariciojunior/video-editor-skills 13:36 - open-math-harness openmathmodel/open-math-harness 14:02 - bambu-bar rolottr/bambu-bar 14:25 - Hi3Dv1.0 hi3d-official/Hi3Dv1.0 14:51 - Plume_Launcher aradhyas8/Plume_Launcher Thank you so much for watching. Please like the video and subscribe to our channel. #github #ai #opensource Notice: The content was created with the assistance of AI and may contain inaccuracies or errors. ▬▬▬▬▬▬ 👋 Contact me 👋 ▬▬▬▬▬▬ ➡ LinkTree: link.githubawesome.com ➡ Buy Me A Coffee link.githubawesome.com [ar] أبرز مشاريع GitHub لهذا الأسبوع #55: owly, ai-job-search, tsrs, dev-null.sh, laya, reylo, openter... هذا هو العدد 55 من نشرة GitHub الأسبوعية لأكثر المشاريع رواجاً. يضم هذا العدد 35 مشروعاً مفتوح المصدر رائجاً على GitHub حالياً. الاشتراك المدفوع في القناة: youtube.com رابط النسخة النصية: githubawesome.com 00:00 - مقدمة 00:11 - owly t4t5/owly 00:38 - ai-job-search ai-job-search-dev/ai-job-search 01:03 - tsrs oxc-project/tsrs 01:29 - new-term-radar zhuyansen/new-term-radar 01:52 - security-audit-skill cloudflare/security-audit-skill 02:18 - dev-null.sh dev-null-sh/dev-null.sh 02:43 - laya NandhaKishorM/laya 03:10 - 3d-model-anything wesbos/3d-model-anything 03:33 - rossark-motion-skill rossark0/rossark-motion-skill 04:02 - reylo colinhacks/reylo 04:29 - openterminal spovalova/openterminal 04:55 - hatchzip xevrion/hatchzip 05:23 - dquickts stencil-hq/dquickts 05:47 - ming-voice JMS1717/ming-voice 06:14 - onkey dsmurrell/onkey 06:41 - Sumi.css vladocar/Sumi.css 07:07 - rl-env-use browser-use/rl-env-use 07:35 - img2interior img2threejs/plugin-interior 08:02 - Rubix-lang tek-sys-hub/Rubix-lang 08:28 - motion2code lovisdotio/motion2code 08:54 - omnara omnara-ai/omnara 09:20 - ELYTerminal ELY-Open-Source/ELYTerminal 09:44 - prompt2rig blendi-remade/prompt2rig 10:08 - video-short petergyang/video-short 10:34 - penmentor AbdullahAlhariri/penmentor 11:02 - rec recursive-oss/rec 11:30 - BitKindle tombkeeper/BitKindle 11:55 - opal xingjian-bai/opal 12:22 - Bursar Samsara-1999/Bursar 12:47 - OpenVLHarness uclanlp/OpenVLHarness 13:10 - video-editor-skills appariciojunior/video-editor-skills 13:36 - open-math-harness openmathmodel/open-math-harness 14:02 - bambu-bar rolottr/bambu-bar 14:25 - Hi3Dv1.0 hi3d-official/Hi3Dv1.0 14:51 - Plume_Launcher aradhyas8/Plume_Launcher شكرًا جزيلًا على المشاهدة. يُرجى الإعجاب بالفيديو والاشتراك في قناتنا. #جيت_هاب #الذكاء_الاصطناعي #المصادر_المفتوحة ملاحظة: تم إنشاء هذا المحتوى بمساعدة الذكاء الاصطناعي، وقد يحتوي على بعض الأخطاء أو عدم الدقة. ▬▬▬▬▬▬ 👋 تواصل معي 👋 ▬▬▬▬▬▬ ➡ لينك تري: link.githubawesome.com ➡ ادعمنا: link.githubawesome.com [bn] গিটহাব ট্রেন্ডিং উইকলি #৫৫: owly, ai-job-search, tsrs, dev-null.sh, laya, reylo, openterminal, onkey এটি গিটহাব ট্রেন্ডিং উইকলি #৫৫। এই মুহূর্তে গিটহাবে ৩৫টি ট্রেন্ডিং ওপেন-সোর্স প্রজেক্ট। পেইড চ্যানেল সাবস্ক্রিপশন: youtube.com টেক্সট ভার্সনের লিঙ্ক: githubawesome.com ০০:০০ - ভূমিকা ০০:১১ - owly t4t5/owly ০০:৩৮ - ai-job-search ai-job-search-dev/ai-job-search ০১:০৩ - tsrs oxc-project/tsrs ০১:২৯ - new-term-radar zhuyansen/new-term-radar ০১:৫২ - security-audit-skill cloudflare/security-audit-skill ০২:১৮ - dev-null.sh dev-null-sh/dev-null.sh ০২:৪৩ - laya NandhaKishorM/laya ০৩:১০ - 3d-model-anything wesbos/3d-model-anything ০৩:৩৩ - rossark-motion-skill rossark0/rossark-motion-skill ০৪:০২ - reylo colinhacks/reylo ০৪:২৯ - openterminal spovalova/openterminal ০৪:৫৫ - hatchzip xevrion/hatchzip ০৫:২৩ - dquickts stencil-hq/dquickts ০৫:৪৭ - ming-voice JMS1717/ming-voice ০৬:১৪ - onkey dsmurrell/onkey ০৬:৪১ - Sumi.css vladocar/Sumi.css ০৭:০৭ - rl-env-use browser-use/rl-env-use ০৭:৩৫ - img2interior img2threejs/plugin-interior ০৮:০২ - Rubix-lang tek-sys-hub/Rubix-lang ০৮:২৮ - motion2code lovisdotio/motion2code ০৮:৫৪ - omnara omnara-ai/omnara ০৯:২০ - ELYTerminal ELY-Open-Source/ELYTerminal ০৯:৪৪ - prompt2rig blendi-remade/prompt2rig ১০:০৮ - ভিডিও-শর্ট petergyang/video-short ১০:৩৪ - পেনমেন্টর AbdullahAlhariri/penmentor ১১:০২ - রেক recursive-oss/rec ১১:৩০ - বিটকিন্ডল tombkeeper/BitKindle ১১:৫৫ - ওপাল xingjian-bai/opal ১২:২২ - বার্সার Samsara-1999/Bursar ১২:৪৭ - ওপেনভিএলহারনেস uclanlp/OpenVLHarness ১৩:১০ - ভিডিও-এডিটর-স্কিলস appariciojunior/video-editor-skills ১৩:৩৬ - ওপেন-ম্যাথ-হারনেস openmathmodel/open-math-harness ১৪:০২ - বাম্বু-বার rolottr/bambu-bar ১৪:২৫ - হাইথ্রিডিভি১.০ hi3d-official/Hi3Dv1.0 ১৪:৫১ - প্লুম_লঞ্চার aradhyas8/Plume_Launcher দেখার জন্য আপনাকে অনেক ধন্যবাদ। অনুগ্রহ করে ভিডিওটি লাইক করুন এবং আমাদের চ্যানেলটি সাবস্ক্রাইব করুন। #github #ai #opensource বিজ্ঞপ্তি: এই কন্টেন্টটি এআই (AI)-এর সহায়তায় তৈরি করা হয়েছে এবং এতে ভুল বা ত্রুটি থাকতে পারে। ▬▬▬▬▬▬ 👋 আমার সাথে যোগাযোগ করুন 👋 ▬▬▬▬▬▬ ➡ লিঙ্কট্রি: link.githubawesome.com ➡ বাই মি এ কফি: link.githubawesome.com [de-DE] GitHub Trending Weekly #55: owly, ai-job-search, tsrs, dev-null.sh, laya, reylo, openterminal, onkey Dies ist GitHub Trending Weekly #55. 35 aktuell angesagte Open-Source-Projekte auf GitHub. Abonnement des kostenpflichtigen Kanals: youtube.com Link zur Textversion: githubawesome.com 00:00 – Einführung 00:11 – owly t4t5/owly 00:38 – ai-job-search ai-job-search-dev/ai-job-search 01:03 – tsrs oxc-project/tsrs 01:29 – new-term-radar zhuyansen/new-term-radar 01:52 – security-audit-skill cloudflare/security-audit-skill 02:18 – dev-null.sh dev-null-sh/dev-null.sh 02:43 - laya NandhaKishorM/laya 03:10 - 3d-model-anything wesbos/3d-model-anything 03:33 - rossark-motion-skill rossark0/rossark-motion-skill 04:02 - reylo colinhacks/reylo 04:29 - openterminal spovalova/openterminal 04:55 - hatchzip xevrion/hatchzip 05:23 - dquickts stencil-hq/dquickts 05:47 - ming-voice JMS1717/ming-voice 06:14 - onkey dsmurrell/onkey 06:41 - Sumi.css vladocar/Sumi.css 07:07 - rl-env-use browser-use/rl-env-use 07:35 - img2interior img2threejs/plugin-interior 08:02 - Rubix-lang tek-sys-hub/Rubix-lang 08:28 - motion2code lovisdotio/motion2code 08:54 - omnara omnara-ai/omnara 09:20 - ELYTerminal ELY-Open-Source/ELYTerminal 09:44 - prompt2rig blendi-remade/prompt2rig 10:08 - video-short petergyang/video-short 10:34 - penmentor AbdullahAlhariri/penmentor 11:02 - rec recursive-oss/rec 11:30 - BitKindle tombkeeper/BitKindle 11:55 - opal xingjian-bai/opal 12:22 - Bursar Samsara-1999/Bursar 12:47 - OpenVLHarness uclanlp/OpenVLHarness 13:10 - Video-Editor-Fähigkeiten appariciojunior/video-editor-skills 13:36 – Open Math Harness openmathmodel/open-math-harness 14:02 – Bambus Bar rolottr/bambu-bar 14:25 – Hi3Dv1.0 hi3d-official/Hi3Dv1.0 14:51 – Plume Launcher aradhyas8/Plume_Launcher Vielen Dank fürs Zuschauen! Bitte liken Sie das Video und abonnieren Sie unseren Kanal. #github #ai #opensource Hinweis: Der Inhalt wurde mithilfe von KI erstellt und kann Ungenauigkeiten oder Fehler enthalten. ▬▬▬▬▬▬ 👋 Kontakt 👋 ▬▬▬▬▬▬ ➡ LinkTree: link.githubawesome.com ➡ Unterstütze mich mit einer Spende: link.githubawesome.com [es-US] GitHub Tendencias Semanal #55: owly, ai-job-search, tsrs, dev-null.sh, laya, reylo, openterminal,... Este es el GitHub Trending Weekly #55. 35 proyectos de código abierto que son tendencia en GitHub en este momento. Suscripción de pago al canal: youtube.com Enlace a la versión en texto: githubawesome.com 00:00 - Introducción 00:11 - owly t4t5/owly 00:38 - ai-job-search ai-job-search-dev/ai-job-search 01:03 - tsrs oxc-project/tsrs 01:29 - new-term-radar zhuyansen/new-term-radar 01:52 - security-audit-skill cloudflare/security-audit-skill 02:18 - dev-null.sh dev-null-sh/dev-null.sh 02:43 - laya NandhaKishorM/laya 03:10 - 3d-model-anything wesbos/3d-model-anything 03:33 - rossark-motion-skill rossark0/rossark-motion-skill 04:02 - reylo colinhacks/reylo 04:29 - openterminal spovalova/openterminal 04:55 - hatchzip xevrion/hatchzip 05:23 - dquickts stencil-hq/dquickts 05:47 - ming-voice JMS1717/ming-voice 06:14 - onkey dsmurrell/onkey 06:41 - Sumi.css vladocar/Sumi.css 07:07 - rl-env-use browser-use/rl-env-use 07:35 - img2interior img2threejs/plugin-interior 08:02 - Rubix-lang tek-sys-hub/Rubix-lang 08:28 - motion2code lovisdotio/motion2code 08:54 - omnara omnara-ai/omnara 09:20 - ELYTerminal ELY-Open-Source/ELYTerminal 09:44 - prompt2rig blendi-remade/prompt2rig 10:08 - video-short petergyang/video-short 10:34 - penmentor AbdullahAlhariri/penmentor 11:02 - rec recursive-oss/rec 11:30 - BitKindle tombkeeper/BitKindle 11:55 - opal xingjian-bai/opal 12:22 - Bursar Samsara-1999/Bursar 12:47 - OpenVLHarness uclanlp/OpenVLHarness 13:10 - video-editor-skills appariciojunior/video-editor-skills 13:36 - open-math-harness openmathmodel/open-math-harness 14:02 - bambu-bar rolottr/bambu-bar 14:25 - Hi3Dv1.0 hi3d-official/Hi3Dv1.0 14:51 - Plume_Launcher aradhyas8/Plume_Launcher Muchas gracias por ver el video. Dale me gusta y suscríbete a nuestro canal. #github #ai #opensource Aviso: El contenido se creó con la ayuda de IA y puede contener imprecisiones o errores. ▬▬▬▬▬▬ 👋 Contáctame 👋 ▬▬▬▬▬▬ ➡ LinkTree: link.githubawesome.com ➡ Invítame a un café: link.githubawesome.com [fr-FR] GitHub Trending Weekly #55 : owly, ai-job-search, tsrs, dev-null.sh, laya, reylo, openterminal, o... Voici le top 55 des tendances hebdomadaires sur GitHub. Découvrez 35 projets open source populaires sur GitHub en ce moment. Abonnement payant à la chaîne : youtube.com Lien vers la version texte : githubwesome.com 00:00 - Introduction 00:11 - owly t4t5/owly 00:38 - ai-job-search ai-job-search-dev/ai-job-search 01:03 - tsrs oxc-project/tsrs 01:29 - new-term-radar zhuyansen/new-term-radar 01:52 - security-audit-skill cloudflare/security-audit-skill 02:18 - dev-null.sh dev-null-sh/dev-null.sh 02:43 - laya NandhaKishorM/laya 03:10 - 3d-model-anything wesbos/3d-model-anything 03:33 - rossark-motion-skill rossark0/rossark-motion-skill 04:02 - reylo colinhacks/reylo 04:29 - openterminal spovalova/openterminal 04:55 - hatchzip xevrion/hatchzip 05:23 - dquickts stencil-hq/dquickts 05:47 - ming-voice JMS1717/ming-voice 06:14 - onkey dsmurrell/onkey 06:41 - Sumi.css vladocar/Sumi.css 07:07 - rl-env-use browser-use/rl-env-use 07:35 - img2interior img2threejs/plugin-interior 08:02 - Rubix-lang tek-sys-hub/Rubix-lang 08:28 - motion2code lovisdotio/motion2code 08:54 - omnara omnara-ai/omnara 09:20 - ELYTerminal ELY-Open-Source/ELYTerminal 09:44 - prompt2rig blendi-remade/prompt2rig 10:08 - video-short petergyang/video-short 10:34 - penmentor AbdullahAlhariri/penmentor 11:02 - rec recursive-oss/rec 11:30 - BitKindle tombkeeper/BitKindle 11:55 - opal xingjian-bai/opal 12:22 - Bursar Samsara-1999/Bursar 12:47 - OpenVLHarness uclanlp/OpenVLHarness 13:10 - Compétences en montage vidéo : appariciojunior/video-editor-skills 13:36 - OpenMathHarness : openmathmodel/open-math-harness 14:02 - Bambu-bar : rolottr/bambu-bar 14:25 - Hi3Dv1.0 : hi3d-official/Hi3Dv1.0 14:51 - Plume_Launcher : aradhyas8/Plume_Launcher Merci beaucoup d'avoir regardé cette vidéo. N'hésitez pas à la liker et à vous abonner à notre chaîne. #github #ai #opensource Avertissement : Ce contenu a été créé avec l'aide d'une IA et peut contenir des inexactitudes ou des erreurs. ▬▬▬▬▬▬ 👋 Contactez-moi 👋 ▬▬▬▬▬▬ ➡ LinkTree : link.githubawesome.com ➡ Offrez-moi un café : link.githubawesome.com [hi] GitHub ट्रेंडिंग वीकली #55: owly, ai-job-search, tsrs, dev-null.sh, laya, reylo, openterminal, onkey यह GitHub ट्रेंडिंग वीकली का 55वां अंक है। GitHub पर इस समय ट्रेंडिंग 35 ओपन-सोर्स प्रोजेक्ट्स की सूची। चैनल की सशुल्क सदस्यता: youtube.com टेक्स्ट संस्करण का लिंक: githubawesome.com 00:00 - परिचय 00:11 - owly t4t5/owly 00:38 - ai-job-search ai-job-search-dev/ai-job-search 01:03 - tsrs oxc-project/tsrs 01:29 - new-term-radar zhuyansen/new-term-radar 01:52 - security-audit-skill cloudflare/security-audit-skill 02:18 - dev-null.sh dev-null-sh/dev-null.sh 02:43 - लाया NandhaKishorM/laya 03:10 - 3डी-मॉडल-एनीथिंग wesbos/3%E0%A4%A1%E0%A5%80-%E0%A4%AE%E0%A5%89%E0%A4%A1%E0%A4%B2-%E0%A4%8F%E0%A4%A8%E0%A5%80%E0%A4%A5%E0%A4%BF%E0%A4%82%E0%A4%97 03:33 - रॉसार्क-मोशन-स्किल rossark0/rossark-motion-skill 04:02 - रेयलो colinhacks/reylo 04:29 - ओपनटर्मिनल spovalova/openterminal 04:55 - हैचज़िप xevrion/hatchzip 05:23 - डीक्विक्ट्स stencil-hq/dquickts 05:47 - मिंग-वॉइस JMS1717/ming-voice 06:14 - onkey dsmurrell/onkey 06:41 - Sumi.css vladocar/Sumi.css 07:07 - rl-env-use browser-use/rl-env-use 07:35 - img2interior img2threejs/plugin-interior 08:02 - Rubix-lang tek-sys-hub/Rubix-lang 08:28 - motion2code lovisdotio/motion2code 08:54 - omnara omnara-ai/omnara 09:20 - ELYTerminal ELY-Open-Source/ELYTerminal 09:44 - prompt2rig blendi-remade/prompt2rig 10:08 - video-short petergyang/video-short 10:34 - penmentor AbdullahAlhariri/penmentor 11:02 - rec recursive-oss/rec 11:30 - BitKindle tombkeeper/BitKindle 11:55 - opal xingjian-bai/opal 12:22 - Bursar Samsara-1999/Bursar 12:47 - OpenVLHarness uclanlp/OpenVLHarness 13:10 - वीडियो एडिटर स्किल्स appariciojunior/video-editor-skills 13:36 - ओपन मैथ हार्नेस openmathmodel/open-math-harness 14:02 - बंबू बार rolottr/bambu-bar 14:25 - Hi3Dv1.0 hi3d-official/Hi3Dv1.0 14:51 - प्लूम लॉन्चर aradhyas8/Plume_Launcher वीडियो देखने के लिए बहुत-बहुत धन्यवाद। कृपया वीडियो को लाइक करें और हमारे चैनल को सब्सक्राइब करें। #github #ai #opensource सूचना: यह सामग्री AI की सहायता से बनाई गई है और इसमें कुछ त्रुटियाँ या अशुद्धियाँ हो सकती हैं। ▬▬▬▬▬▬ 👋 मुझसे संपर्क करें 👋 ▬▬▬▬▬▬ ➡ लिंक ट्री: link.githubawesome.com ➡ मुझे कॉफ़ी पिलाएँ: link.githubawesome.com [id] GitHub Trending Mingguan #55: owly, ai-job-search, tsrs, dev-null.sh, laya, reylo, openterminal, ... Ini adalah GitHub Trending Weekly #55. 35 proyek open-source yang sedang tren di GitHub saat ini. Langganan saluran berbayar: youtube.com Tautan versi teks: githubawesome.com 00:00 - Pendahuluan 00:11 - owly t4t5/owly 00:38 - ai-job-search ai-job-search-dev/ai-job-search 01:03 - tsrs oxc-project/tsrs 01:29 - new-term-radar zhuyansen/new-term-radar 01:52 - security-audit-skill cloudflare/security-audit-skill 02:18 - dev-null.sh dev-null-sh/dev-null.sh 02:43 - laya NandhaKishorM/laya 03:10 - 3d-model-anything wesbos/3d-model-anything 03:33 - rossark-motion-skill rossark0/rossark-motion-skill 04:02 - reylo colinhacks/reylo 04:29 - openterminal spovalova/openterminal 04:55 - hatchzip xevrion/hatchzip 05:23 - dquickts stencil-hq/dquickts 05:47 - ming-voice JMS1717/ming-voice 06:14 - onkey dsmurrell/onkey 06:41 - Sumi.css vladocar/Sumi.css 07:07 - rl-env-use browser-use/rl-env-use 07:35 - img2interior img2threejs/plugin-interior 08:02 - Rubix-lang tek-sys-hub/Rubix-lang 08:28 - motion2code lovisdotio/motion2code 08:54 - omnara omnara-ai/omnara 09:20 - ELYTerminal ELY-Open-Source/ELYTerminal 09:44 - prompt2rig blendi-remade/prompt2rig 10:08 - video-short petergyang/video-short 10:34 - penmentor AbdullahAlhariri/penmentor 11:02 - rec recursive-oss/rec 11:30 - BitKindle tombkeeper/BitKindle 11:55 - opal xingjian-bai/opal 12:22 - Bursar Samsara-1999/Bursar 12:47 - OpenVLHarness uclanlp/OpenVLHarness 13:10 - video-editor-skills appariciojunior/video-editor-skills 13:36 - open-math-harness openmathmodel/open-math-harness 14:02 - bambu-bar rolottr/bambu-bar 14:25 - Hi3Dv1.0 hi3d-official/Hi3Dv1.0 14:51 - Plume_Launcher aradhyas8/Plume_Launcher Terima kasih banyak telah menonton. Silakan sukai video ini dan berlangganan saluran kami. #github #ai #opensource Peringatan: Konten ini dibuat dengan bantuan AI dan mungkin mengandung ketidakakuratan atau kesalahan. ▬▬▬▬▬▬ 👋 Hubungi saya 👋 ▬▬▬▬▬▬ ➡ LinkTree: link.githubawesome.com ➡ Dukung saya dengan membeli kopi: link.githubawesome.com [it] GitHub Trending Weekly #55: owly, ai-job-search, tsrs, dev-null.sh, laya, reylo, openterminal, onkey Questa è la rubrica settimanale "GitHub Trending #55". 35 progetti open source di tendenza su GitHub in questo momento. Abbonamento a pagamento al canale: youtube.com Link alla versione testuale: githubawesome.com 00:00 - Introduzione 00:11 - owly t4t5/owly 00:38 - ai-job-search ai-job-search-dev/ai-job-search 01:03 - tsrs oxc-project/tsrs 01:29 - new-term-radar zhuyansen/new-term-radar 01:52 - security-audit-skill cloudflare/security-audit-skill 02:18 - dev-null.sh Italiano: dev-null-sh/dev-null.sh 02:43 - laya NandhaKishorM/laya 03:10 - 3d-model-anything wesbos/3d-model-anything 03:33 - rossark-motion-skill rossark0/rossark-motion-skill 04:02 - reylo colinhacks/reylo 04:29 - openterminal spovalova/openterminal 04:55 - hatchzip xevrion/hatchzip 05:23 - dquickts stencil-hq/dquickts 05:47 - ming-voice Italiano: JMS1717/ming-voice 06:14 - onkey dsmurrell/onkey 06:41 - Sumi.css vladocar/Sumi.css 07:07 - rl-env-use browser-use/rl-env-use 07:35 - img2interior img2threejs/plugin-interior 08:02 - Rubix-lang tek-sys-hub/Rubix-lang 08:28 - motion2code lovisdotio/motion2code 08:54 - omnara omnara-ai/omnara 09:20 - ELYTerminal Italiano: ELY-Open-Source/ELYTerminal 09:44 - prompt2rig blendi-remade/prompt2rig 10:08 - video-short petergyang/video-short 10:34 - penmentor AbdullahAlhariri/penmentor 11:02 - rec recursive-oss/rec 11:30 - BitKindle tombkeeper/BitKindle 11:55 - opal xingjian-bai/opal 12:22 - Bursar Samsara-1999/Bursar 12:47 - OpenVLHarness Italiano: uclanlp/OpenVLHarness 13:10 - Video Editor Skills appariciojunior/video-editor-skills 13:36 - OpenMath Harness openmathmodel/open-math-harness 14:02 - Bambu Bar rolottr/bambu-bar 14:25 - Hi3Dv1.0 hi3d-official/Hi3Dv1.0 14:51 - Plume Launcher aradhyas8/Plume Launcher Grazie mille per aver guardato il video. Metti mi piace e iscriviti al nostro canale. #github #ai #opensource Nota: il contenuto è stato creato con l'aiuto dell'IA e potrebbe contenere imprecisioni o errori. ▬▬▬▬▬▬ 👋 Contattami 👋 ▬▬▬▬▬▬ ➡ LinkTree: link.githubawesome.com ➡ Offrimi un caffè link.githubawesome.com [iw] GitHub Trending Weekly #55: owly, ai-job-search, tsrs, dev-null.sh, laya, reylo, openterminal, onkey זהו מגזין GitHub Trending Weekly #55. 35 פרויקטים בקוד פתוח פופולריים ב-GitHub כרגע. מנוי לערוץ בתשלום: youtube.com קישור לגרסת טקסט: githubawesome.com 00:00 - מבוא 00:11 - owly t4t5/owly 00:38 - ai-job-search ai-job-search-dev/ai-job-search 01:03 - tsrs oxc-project/tsrs 01:29 - new-term-radar zhuyansen/new-term-radar 01:52 - security-audit-skill cloudflare/security-audit-skill 02:18 - dev-null.sh dev-null-sh/dev-null.sh 02:43 - לאיה NandhaKishorM/laya 03:10 - מודל תלת-ממדי wesbos/3d-model-anything 03:33 - rossark-motion-skill rossark0/rossark-motion-skill 04:02 - ריילו colinhacks/reylo 04:29 - טרמינל פתוח spovalova/openterminal 04:55 - האצ'יפ xevrion/hatchzip 05:23 - dquickts stencil-hq/dquickts 05:47 - מינג-קול JMS1717/ming-voice 06:14 - onkey dsmurrell/onkey 06:41 - Sumi.css vladocar/Sumi.css 07:07 - rl-env-use browser-use/rl-env-use 07:35 - img2interior img2threejs/plugin-interior 08:02 - Rubix-lang tek-sys-hub/Rubix-lang 08:28 - motion2code lovisdotio/motion2code 08:54 - omnara omnara-ai/omnara 09:20 - ELYTerminal ELY-Open-Source/ELYTerminal 09:44 - prompt2rig blendi-remade/prompt2rig 10:08 - סרטון קצר petergyang/video-short 10:34 - penmentor AbdullahAlhariri/penmentor 11:02 - rec recursive-oss/rec 11:30 - BitKindle tombkeeper/BitKindle 11:55 - opal xingjian-bai/opal 12:22 - Bursar Samsara-1999/Bursar 12:47 - OpenVLHarness uclanlp/OpenVLHarness 13:10 - מיומנויות עריכת וידאו appariciojunior/video-editor-skills 13:36 - רתמת מתמטיקה פתוחה openmathmodel/open-math-harness 14:02 - bambu-bar rolottr/bambu-bar 14:25 - Hi3Dv1.0 hi3d-official/Hi3Dv1.0 14:51 - Plume_Launcher aradhyas8/Plume_Launcher תודה רבה שצפיתם. אנא עשו לייק לסרטון והירשמו לערוץ שלנו. #github #ai #opensource הערה: התוכן נוצר בעזרת בינה מלאכותית ועשוי להכיל אי דיוקים או שגיאות. ▬▬▬▬▬▬ 👋 צרו איתי קשר 👋 ▬▬▬▬▬▬▬ ➡ לינקטרי: link.githubawesome.com ➡ תקנה לי קפה link.githubawesome.com [ja] GitHub週間トレンド #55: owly, ai-job-search, tsrs, dev-null.sh, laya, reylo, openterminal, onkey こちらはGitHubトレンドウィークリー第55回です。現在GitHubで注目を集めているオープンソースプロジェクト35件をご紹介します。 有料チャンネル登録：youtube.com テキスト版リンク：githubawesome.com 00:00 - はじめに 00:11 - owly t4t5/owly 00:38 - ai-job-search ai-job-search-dev/ai-job-search 01:03 - tsrs oxc-project/tsrs 01:29 - new-term-radar zhuyansen/new-term-radar 01:52 - security-audit-skill cloudflare/security-audit-skill 02:18 - dev-null.sh dev-null-sh/dev-null.sh 02:43 - laya NandhaKishorM/laya 03:10 - 3d-model-anything wesbos/3d-model-anything 03:33 - rossark-motion-skill rossark0/rossark-motion-skill 04:02 - reylo colinhacks/reylo 04:29 - openterminal spovalova/openterminal 04:55 - hatchzip xevrion/hatchzip 05:23 - dquickts stencil-hq/dquickts 05:47 - ming-voice JMS1717/ming-voice 06:14 - onkey dsmurrell/onkey 06:41 - Sumi.css vladocar/Sumi.css 07:07 - rl-env-use browser-use/rl-env-use 07:35 - img2interior img2threejs/plugin-interior 08:02 - Rubix-lang tek-sys-hub/Rubix-lang 08:28 - motion2code lovisdotio/motion2code 08:54 - omnara omnara-ai/omnara 09:20 - ELYTerminal ELY-Open-Source/ELYTerminal 09:44 - prompt2rig blendi-remade/prompt2rig 10:08 - video-short petergyang/video-short 10:34 - penmentor AbdullahAlhariri/penmentor 11:02 - rec recursive-oss/rec 11:30 - BitKindle tombkeeper/BitKindle 11:55 - opal xingjian-bai/opal 12:22 - Bursar Samsara-1999/Bursar 12:47 - OpenVLHarness uclanlp/OpenVLHarness 13:10 - video-editor-skills appariciojunior/video-editor-skills 13:36 - open-math-harness openmathmodel/open-math-harness 14:02 - bambu-bar rolottr/bambu-bar 14:25 - Hi3Dv1.0 hi3d-official/Hi3Dv1.0 14:51 - Plume_Launcher aradhyas8/Plume_Launcher ご視聴いただきありがとうございました。動画への「いいね」とチャンネル登録をお願いします。 #github #ai #opensource 注意：このコンテンツはAIの支援を受けて作成されたため、不正確な情報や誤りが含まれている可能性があります。 ▬▬▬▬▬▬ 👋 ご連絡ください 👋 ▬▬▬▬▬▬ ➡ LinkTree: link.githubawesome.com ➡ Buy Me A Coffee: link.githubawesome.com [ko] GitHub 주간 트렌딩 #55: owly, ai-job-search, tsrs, dev-null.sh, laya, reylo, openterminal, onkey GitHub 주간 인기 프로젝트 #55입니다. 지금 GitHub에서 가장 인기 있는 오픈소스 프로젝트 35개를 소개합니다. 유료 채널 구독: youtube.com 텍스트 버전 링크: githubwesome.com 00:00 - 소개 00:11 - owly t4t5/owly 00:38 - ai-job-search ai-job-search-dev/ai-job-search 01:03 - tsrs oxc-project/tsrs 01:29 - new-term-radar zhuyansen/new-term-radar 01:52 - security-audit-skill cloudflare/security-audit-skill 02:18 - dev-null.sh dev-null-sh/dev-null.sh 02:43 - laya NandhaKishorM/laya 03:10 - 3d-model-anything wesbos/3d-model-anything 03:33 - rossark-motion-skill rossark0/rossark-motion-skill 04:02 - reylo colinhacks/reylo 04:29 - openterminal spovalova/openterminal 04:55 - hatchzip xevrion/hatchzip 05:23 - dquickts stencil-hq/dquickts 05:47 - ming-voice JMS1717/ming-voice 06:14 - onkey dsmurrell/onkey 06:41 - Sumi.css vladocar/Sumi.css 07:07 - rl-env-use browser-use/rl-env-use 07:35 - img2interior img2threejs/plugin-interior 08:02 - Rubix-lang tek-sys-hub/Rubix-lang 08:28 - motion2code lovisdotio/motion2code 08:54 - omnara omnara-ai/omnara 09:20 - ELYTerminal ELY-Open-Source/ELYTerminal 09:44 - prompt2rig blendi-remade/prompt2rig 10:08 - video-short petergyang/video-short 10:34 - penmentor AbdullahAlhariri/penmentor 11:02 - rec recursive-oss/rec 11:30 - BitKindle tombkeeper/BitKindle 11:55 - opal xingjian-bai/opal 12:22 - Bursar Samsara-1999/Bursar 12:47 - OpenVLHarness uclanlp/OpenVLHarness 13:10 - video-editor-skills appariciojunior/video-editor-skills 13:36 - open-math-harness openmathmodel/open-math-harness 14:02 - bambu-bar rolottr/bambu-bar 14:25 - Hi3Dv1.0 hi3d-official/Hi3Dv1.0 14:51 - Plume_Launcher aradhyas8/Plume_Launcher 시청해 주셔서 감사합니다. 영상에 좋아요를 누르고 채널 구독도 부탁드립니다. #github #ai #opensource 주의: 본 콘텐츠는 AI를 이용하여 제작되었으며, 부정확하거나 오류가 포함될 수 있습니다. ▬▬▬▬▬▬ 👋 연락처 👋 ▬▬▬▬▬▬ ➡ 링크트리: link.githubawesome.com ➡ 커피 한 잔 사주세요: link.githubawesome.com [ml] GitHub ട്രെൻഡിംഗ് വീക്ക്‌ലി #55: owly, ai-job-search, tsrs, dev-null.sh, laya, reylo, opentermina... ഇതാണ് GitHub ട്രെൻഡിംഗ് വീക്ക്‌ലി #55. GitHub-ൽ ഇപ്പോൾ ട്രെൻഡിംഗ് ആയ 35 ഓപ്പൺ സോഴ്‌സ് പ്രോജക്ടുകൾ. പണമടച്ചുള്ള ചാനൽ സബ്‌സ്‌ക്രിപ്‌ഷൻ: youtube.com ടെക്‌സ്റ്റ് പതിപ്പ് ലിങ്ക്: githubawesome.com 00:00 - ആമുഖം 00:11 - owly t4t5/owly 00:38 - ai-job-search ai-job-search-dev/ai-job-search 01:03 - tsrs oxc-project/tsrs 01:29 - new-term-radar zhuyansen/new-term-radar 01:52 - security-audit-skill cloudflare/security-audit-skill 02:18 - dev-null.sh dev-null-sh/dev-null.sh 02:43 - ലായ NandhaKishorM/laya 03:10 - 3d-model-anything wesbos/3d-model-anything 03:33 - റോസാർക്ക്-മോഷൻ-സ്കിൽ rossark0/rossark-motion-skill 04:02 - റെയ്ലോ colinhacks/reylo 04:29 - ഓപ്പൺടെർമിനൽ spovalova/openterminal 04:55 - ഹാച്ച്സിപ്പ് xevrion/hatchzip 05:23 - dquickts stencil-hq/dquickts 05:47 - മിംഗ്-വോയ്‌സ് JMS1717/ming-voice 06:14 - onkey dsmurrell/onkey 06:41 - Sumi.css vladocar/Sumi.css 07:07 - rl-env-use browser-use/rl-env-use 07:35 - img2interior img2threejs/plugin-interior 08:02 - Rubix-lang tek-sys-hub/Rubix-lang 08:28 - motion2code lovisdotio/motion2code 08:54 - omnara omnara-ai/omnara 09:20 - ELYTerminal ELY-Open-Source/ELYTerminal 09:44 - prompt2rig blendi-remade/prompt2rig 10:08 - വീഡിയോ-ഷോർട്ട് petergyang/video-short 10:34 - പെൻമെന്റർ AbdullahAlhariri/penmentor 11:02 - rec recursive-oss/rec 11:30 - BitKindle tombkeeper/BitKindle 11:55 - opal xingjian-bai/opal 12:22 - ബർസാർ Samsara-1999/Bursar 12:47 - ഓപ്പൺവിഎൽഹാർനെസ് uclanlp/OpenVL%E0%B4%B9%E0%B4%BE%E0%B5%BC%E0%B4%A8%E0%B5%86%E0%B4%B8%E0%B5%8D 13:10 - video-editor-skills appariciojunior/video-editor-skills 13:36 - open-math-harness openmathmodel/open-math-harness 14:02 - bambu-bar rolottr/bambu-bar 14:25 - Hi3Dv1.0 hi3d-official/Hi3Dv1.0 14:51 - Plume_Launcher aradhyas8/Plume_Launcher കണ്ടതിന് വളരെ നന്ദി. ദയവായി വീഡിയോ ലൈക്ക് ചെയ്യുകയും ഞങ്ങളുടെ ചാനൽ സബ്‌സ്‌ക്രൈബ് ചെയ്യുകയും ചെയ്യുക. #github #ai #opensource ശ്രദ്ധിക്കുക: ഉള്ളടക്കം AI യുടെ സഹായത്തോടെ സൃഷ്ടിച്ചതാണ്, അതിൽ കൃത്യതയില്ലായ്മകളോ പിശകുകളോ അടങ്ങിയിരിക്കാം. ▬▬▬▬▬▬ 👋 എന്നെ ബന്ധപ്പെടുക 👋 ▬▬▬▬▬▬ ➡ ലിങ്ക്ട്രീ: link.githubawesome.com ➡ എനിക്ക് ഒരു കാപ്പി വാങ്ങിത്തരൂ link.githubawesome.com [nl-NL] GitHub Trending Weekly #55: owly, ai-job-search, tsrs, dev-null.sh, laya, reylo, openterminal, onkey Dit is GitHub Trending Weekly #55. 35 populaire open-sourceprojecten op GitHub van dit moment. Betaald kanaalabonnement: youtube.com Link naar tekstversie: githubawesome.com 00:00 - Introductie 00:11 - owly t4t5/owly 00:38 - ai-job-search ai-job-search-dev/ai-job-search 01:03 - tsrs oxc-project/tsrs 01:29 - new-term-radar zhuyansen/new-term-radar 01:52 - security-audit-skill cloudflare/security-audit-skill 02:18 - dev-null.sh dev-null-sh/dev-null.sh 02:43 - laya NandhaKishorM/laya 03:10 - 3d-model-anything wesbos/3d-model-anything 03:33 - rossark-motion-skill rossark0/rossark-motion-skill 04:02 - reylo colinhacks/reylo 04:29 - openterminal spovalova/openterminal 04:55 - hatchzip xevrion/hatchzip 05:23 - dquickts stencil-hq/dquickts 05:47 - ming-voice JMS1717/ming-voice 06:14 - onkey dsmurrell/onkey 06:41 - Sumi.css vladocar/Sumi.css 07:07 - rl-env-use browser-use/rl-env-use 07:35 - img2interior img2threejs/plugin-interior 08:02 - Rubix-lang tek-sys-hub/Rubix-lang 08:28 - motion2code lovisdotio/motion2code 08:54 - omnara omnara-ai/omnara 09:20 - ELYTerminal ELY-Open-Source/ELYTerminal 09:44 - prompt2rig blendi-remade/prompt2rig 10:08 - video-short petergyang/video-short 10:34 - penmentor AbdullahAlhariri/penmentor 11:02 - rec recursive-oss/rec 11:30 - BitKindle tombkeeper/BitKindle 11:55 - opal xingjian-bai/opal 12:22 - Bursar Samsara-1999/Bursar 12:47 - OpenVLHarness uclanlp/OpenVLHarness 13:10 - video-editor-skills appariciojunior/video-editor-skills 13:36 - open-math-harness openmathmodel/open-math-harness 14:02 - bambu-bar rolottr/bambu-bar 14:25 - Hi3Dv1.0 hi3d-official/Hi3Dv1.0 14:51 - Plume_Launcher aradhyas8/Plume_Launcher Hartelijk dank voor het kijken. Geef de video een like en abonneer je op ons kanaal. #github #ai #opensource Let op: De inhoud is gemaakt met behulp van AI en kan onnauwkeurigheden of fouten bevatten. ▬▬▬▬▬▬ 👋 Neem contact met me op 👋 ▬▬▬▬▬▬ ➡ LinkTree: link.githubawesome.com ➡ Koop me een koffie: link.githubawesome.com [pa] GitHub ਟ੍ਰੈਂਡਿੰਗ ਵੀਕਲੀ #55: owly, ai-job-search, tsrs, dev-null.sh, laya, reylo, openterminal, onkey ਇਹ GitHub ਟ੍ਰੈਂਡਿੰਗ ਵੀਕਲੀ #55 ਹੈ। GitHub 'ਤੇ ਇਸ ਵੇਲੇ 35 ਟ੍ਰੈਂਡਿੰਗ ਓਪਨ-ਸੋਰਸ ਪ੍ਰੋਜੈਕਟ। ਭੁਗਤਾਨਸ਼ੁਦਾ ਚੈਨਲ ਗਾਹਕੀ: youtube.com ਟੈਕਸਟ ਵਰਜਨ ਲਿੰਕ: githubawesome.com 00:00 - ਜਾਣ-ਪਛਾਣ 00:11 - owly t4t5/owly 00:38 - ai-job-search ai-job-search-dev/ai-job-search 01:03 - tsrs oxc-project/tsrs 01:29 - new-term-radar zhuyansen/new-term-radar 01:52 - security-audit-skill cloudflare/security-audit-skill 02:18 - dev-null.sh dev-null-sh/dev-null.sh 02:43 - ਲਾਯਾ NandhaKishorM/laya 03:10 - 3d-model-anything wesbos/3d-model-anything 03:33 - ਰੋਸਾਰਕ-ਮੋਸ਼ਨ-ਸਕਿੱਲ rossark0/rossark-motion-skill 04:02 - ਰੀਲੋ colinhacks/reylo 04:29 - ਓਪਨਟਰਮੀਨਲ spovalova/openterminal 04:55 - ਹੈਚਜ਼ਿਪ xevrion/hatchzip 05:23 - dquickts stencil-hq/dquickts 05:47 - ਮਿੰਗ-ਵੌਇਸ JMS1717/ming-voice 06:14 - ਓਨਕੀ dsmurrell/onkey 06:41 - Sumi.css vladocar/Sumi.css 07:07 - rl-env-use browser-use/rl-env-use 07:35 - img2interior img2threejs/plugin-interior 08:02 - Rubix-lang tek-sys-hub/Rubix-lang 08:28 - motion2code lovisdotio/motion2code 08:54 - omnara omnara-ai/omnara 09:20 - ELYTerminal ELY-Open-Source/ELYTerminal 09:44 - prompt2rig blendi-remade/prompt2rig 10:08 - ਵੀਡੀਓ-ਸ਼ਾਰਟ petergyang/video-short 10:34 - ਪੈਨਮੈਂਟਰ AbdullahAlhariri/penmentor 11:02 - rec recursive-oss/rec 11:30 - ਬਿਟਕਿੰਡਲ tombkeeper/BitKindle 11:55 - ਓਪਲ xingjian-bai/opal 12:22 - ਬਰਸਰ Samsara-1999/Bursar 12:47 - ਓਪਨਵੀਐਲਹਾਰਨੈਸ uclanlp/OpenVL%E0%A8%B9%E0%A8%BE%E0%A8%B0%E0%A8%A8%E0%A9%88%E0%A8%B8 13:10 - ਵੀਡੀਓ-ਐਡੀਟਰ-ਸਕਿੱਲਸ appariciojunior/video-editor-skills 13:36 - open-math-harness openmathmodel/open-math-harness 14:02 - bambu-bar rolottr/bambu-bar 14:25 - Hi3Dv1.0 hi3d-official/Hi3Dv1.0 14:51 - Plume_Launcher aradhyas8/Plume_Launcher ਦੇਖਣ ਲਈ ਤੁਹਾਡਾ ਬਹੁਤ ਧੰਨਵਾਦ। ਕਿਰਪਾ ਕਰਕੇ ਵੀਡੀਓ ਨੂੰ ਪਸੰਦ ਕਰੋ ਅਤੇ ਸਾਡੇ ਚੈਨਲ ਨੂੰ ਸਬਸਕ੍ਰਾਈਬ ਕਰੋ। #github #ai #opensource ਨੋਟਿਸ: ਸਮੱਗਰੀ AI ਦੀ ਸਹਾਇਤਾ ਨਾਲ ਬਣਾਈ ਗਈ ਸੀ ਅਤੇ ਇਸ ਵਿੱਚ ਗਲਤੀਆਂ ਜਾਂ ਗਲਤੀਆਂ ਹੋ ਸਕਦੀਆਂ ਹਨ। ▬▬▬▬▬▬ 👋 ਮੇਰੇ ਨਾਲ ਸੰਪਰਕ ਕਰੋ 👋 ▬▬▬▬▬▬ ➡ ਲਿੰਕਟ੍ਰੀ: link.githubawesome.com ➡ ਮੈਨੂੰ ਇੱਕ ਕੌਫੀ ਖਰੀਦੋ link.githubawesome.com [pl] GitHub Trending Weekly #55: owly, ai-job-search, tsrs, dev-null.sh, laya, reylo, openterminal, onkey Oto GitHub Trending Weekly nr 55. 35 najpopularniejszych projektów open source na GitHubie. Płatna subskrypcja kanału: youtube.com Link do wersji tekstowej: githubwesome.com 00:00 - Wprowadzenie 00:11 - owly t4t5/owly 00:38 - ai-job-search ai-job-search-dev/ai-job-search 01:03 - tsrs oxc-project/tsrs 01:29 - new-term-radar zhuyansen/new-term-radar 01:52 - security-audit-skill cloudflare/security-audit-skill 02:18 - dev-null.sh dev-null-sh/dev-null.sh 02:43 - laya NandhaKishorM/laya 03:10 - 3d-model-anything wesbos/3d-model-anything 03:33 - rossark-motion-skill rossark0/rossark-motion-skill 04:02 - reylo colinhacks/reylo 04:29 - openterminal spovalova/openterminal 04:55 - hatchzip xevrion/hatchzip 05:23 - dquickts stencil-hq/dquickts 05:47 - ming-voice JMS1717/ming-voice 06:14 - onkey dsmurrell/onkey 06:41 - Sumi.css vladocar/Sumi.css 07:07 - rl-env-use browser-use/rl-env-use 07:35 - img2interior img2threejs/plugin-interior 08:02 - Rubix-lang tek-sys-hub/Rubix-lang 08:28 - motion2code lovisdotio/motion2code 08:54 - omnara omnara-ai/omnara 09:20 - ELYTerminal ELY-Open-Source/ELYTerminal 09:44 - prompt2rig blendi-remade/prompt2rig 10:08 - krótki film petergyang/video-short 10:34 - penmentor AbdullahAlhariri/penmentor 11:02 - rec recursive-oss/rec 11:30 - BitKindle tombkeeper/BitKindle 11:55 - opal xingjian-bai/opal 12:22 - Bursar Samsara-1999/Bursar 12:47 - OpenVLHarness uclanlp/OpenVLHarness 13:10 - umiejętności edytora wideo appariciojunior/video-editor-skills 13:36 - open-math-harness openmathmodel/open-math-harness 14:02 - bambu-bar rolottr/bambu-bar 14:25 - Hi3Dv1.0 hi3d-official/Hi3Dv1.0 14:51 - Plume_Launcher aradhyas8/Plume_Launcher Dziękujemy za obejrzenie. Polub film i zasubskrybuj nasz kanał. #github #ai #opensource Uwaga: Treść została stworzona przy pomocy sztucznej inteligencji i może zawierać nieścisłości lub błędy. ▬▬▬▬▬▬ 👋 Skontaktuj się ze mną 👋 ▬▬▬▬▬▬ ➡ LinkTree: link.githubwesome.com ➡ Kup mi kawę link.githubwesome.com [pt-BR] GitHub Trending Weekly #55: owly, ai-job-search, tsrs, dev-null.sh, laya, reylo, openterminal, onkey Esta é a lista #55 dos projetos de código aberto mais populares do GitHub neste momento. 35 projetos de código aberto em alta no GitHub. Assinatura paga do canal: youtube.com Link para a versão em texto: githubawesome.com 00:00 - Introdução 00:11 - owly t4t5/owly 00:38 - ai-job-search ai-job-search-dev/ai-job-search 01:03 - tsrs oxc-project/tsrs 01:29 - new-term-radar zhuyansen/new-term-radar 01:52 - security-audit-skill cloudflare/security-audit-skill 02:18 - dev-null.sh dev-null-sh/dev-null.sh 02:43 - laya NandhaKishorM/laya 03:10 - 3d-model-anything wesbos/3d-model-anything 03:33 - rossark-motion-skill rossark0/rossark-motion-skill 04:02 - reylo colinhacks/reylo 04:29 - openterminal spovalova/openterminal 04:55 - hatchzip xevrion/hatchzip 05:23 - dquickts stencil-hq/dquickts 05:47 - ming-voice JMS1717/ming-voice 06:14 - onkey dsmurrell/onkey 06:41 - Sumi.css vladocar/Sumi.css 07:07 - rl-env-use browser-use/rl-env-use 07:35 - img2interior img2threejs/plugin-interior 08:02 - Rubix-lang tek-sys-hub/Rubix-lang 08:28 - motion2code lovisdotio/motion2code 08:54 - omnara omnara-ai/omnara 09:20 - ELYTerminal ELY-Open-Source/ELYTerminal 09:44 - prompt2rig blendi-remade/prompt2rig 10:08 - video-short petergyang/video-short 10:34 - penmentor AbdullahAlhariri/penmentor 11:02 - rec recursive-oss/rec 11:30 - BitKindle tombkeeper/BitKindle 11:55 - opal xingjian-bai/opal 12:22 - Bursar Samsara-1999/Bursar 12:47 - OpenVLHarness uclanlp/OpenVLHarness 13:10 - video-editor-skills appariciojunior/video-editor-skills 13:36 - open-math-harness openmathmodel/open-math-harness 14:02 - bambu-bar rolottr/bambu-bar 14:25 - Hi3Dv1.0 hi3d-official/Hi3Dv1.0 14:51 - Plume_Launcher aradhyas8/Plume_Launcher Muito obrigado por assistir. Por favor, curta o vídeo e inscreva-se no nosso canal. #github #ai #opensource Aviso: O conteúdo foi criado com o auxílio de IA e pode conter imprecisões ou erros. ▬▬▬▬▬▬ 👋 Entre em contato comigo 👋 ▬▬▬▬▬▬ ➡ LinkTree: link.githubawesome.com ➡ Compre-me um café: link.githubawesome.com [ru] GitHub Trending Weekly №55: owly, ai-job-search, tsrs, dev-null.sh, laya, reylo, openterminal, onkey Это еженедельный обзор трендов GitHub № 55. 35 самых популярных проектов с открытым исходным кодом на GitHub прямо сейчас. Платная подписка на канал: youtube.com Ссылка на текстовую версию: githubawesome.com 00:00 - Введение 00:11 - owly t4t5/owly 00:38 - ai-job-search ai-job-search-dev/ai-job-search 01:03 - tsrs oxc-project/tsrs 01:29 - new-term-radar zhuyansen/new-term-radar 01:52 - security-audit-skill cloudflare/security-audit-skill 02:18 - dev-null.sh dev-null-sh/dev-null.sh 02:43 - laya NandhaKishorM/laya 03:10 - 3d-model-anything wesbos/3d-model-anything 03:33 - rossark-motion-skill rossark0/rossark-motion-skill 04:02 - reylo colinhacks/reylo 0