@stacksjs/defaults 0.74.33 → 0.74.35

package/app/Actions/Dashboard/Remote/ssh-runner.ts

@@ -0,0 +1,94 @@
+import type { RemoteAuditSink, RemoteCommand, RemoteHost, RemoteRunner } from './remote-commands'
+import { chmodSync, mkdtempSync, rmSync, writeFileSync } from 'node:fs'
+import { tmpdir } from 'node:os'
+import { join } from 'node:path'
+import { log } from '@stacksjs/logging'
+import { sshArgv } from './remote-commands'
+
+/**
+ * The SSH transport and audit sink behind `runRemoteCommand`
+ * (stacksjs/stacks#960).
+ *
+ * Split from `remote-commands.ts` so the resolution, authorization and audit
+ * ordering can be tested without a network or a database - the same split
+ * `file-manager.ts` makes with its `Manager` parameter.
+ */
+
+/**
+ * A runner for one host, with that host's pinned keys written to a file only
+ * this process can read.
+ *
+ * The known-hosts file is created per run and removed afterwards rather than
+ * kept in `~/.ssh`: the app server may reach several hosts with different
+ * operators, and a shared file is one where a stale entry for a decommissioned
+ * box silently authorizes whoever picked up its address.
+ */
+export function createSshRunner(host: RemoteHost, command: RemoteCommand): RemoteRunner {
+  return async (_argv, options) => {
+    const dir = mkdtempSync(join(tmpdir(), 'stacks-remote-'))
+    const knownHostsPath = join(dir, 'known_hosts')
+
+    try {
+      writeFileSync(knownHostsPath, host.knownHosts.endsWith('\n') ? host.knownHosts : `${host.knownHosts}\n`)
+      // ssh refuses a known-hosts file others can write.
+      chmodSync(knownHostsPath, 0o600)
+
+      const proc = Bun.spawn(sshArgv(host, command, knownHostsPath), {
+        stdin: 'ignore',
+        stdout: 'pipe',
+        stderr: 'pipe',
+      })
+
+      // A run that has not finished is killed rather than left. Without this a
+      // hung ssh holds a process and a request until the server restarts.
+      let timedOut = false
+      const timer = setTimeout(() => {
+        timedOut = true
+        proc.kill()
+      }, options.timeoutMs)
+
+      try {
+        const [stdout, stderr, exitCode] = await Promise.all([
+          new Response(proc.stdout).text(),
+          new Response(proc.stderr).text(),
+          proc.exited,
+        ])
+
+        return { exitCode, stdout, stderr, timedOut }
+      }
+      finally {
+        clearTimeout(timer)
+      }
+    }
+    finally {
+      // Always, including on the failure path: a pinned-key file left in the
+      // temp directory on every run is both a leak and a growing surface.
+      rmSync(dir, { force: true, recursive: true })
+    }
+  }
+}
+
+/**
+ * The audit sink that writes to the application log.
+ *
+ * The log rather than a table, deliberately. A remote-command record is
+ * append-only evidence about who did what, and the dashboard's own database is
+ * the thing an operator with dashboard access could edit. Shipping to whatever
+ * the app's logging is already configured to ship to keeps it outside the blast
+ * radius of the surface it audits.
+ *
+ * An application that wants these queryable can pass its own sink; the
+ * interface is two functions.
+ */
+export const loggingAuditSink: RemoteAuditSink = {
+  async started(entry) {
+    // Not `log.debug`: this is the record, and a level nobody ships in
+    // production is the same as not recording it.
+    await log.info(`[remote] ${entry.user} started ${entry.commandKey} on ${entry.hostKey} at ${entry.at}`)
+  },
+
+  async finished(entry) {
+    const outcome = entry.timedOut ? 'timed out' : `exited ${entry.exitCode}`
+    await log.info(`[remote] ${entry.user} finished ${entry.commandKey} on ${entry.hostKey}: ${outcome} in ${entry.durationMs}ms`)
+  },
+}

package/app/Jobs/OptimizeStorageImageJob.ts

@@ -0,0 +1,74 @@
+import { mkdtemp, rm, writeFile } from 'node:fs/promises'
+import { tmpdir } from 'node:os'
+import { basename, join } from 'node:path'
+import { image } from '@stacksjs/image'
+import { log } from '@stacksjs/logging'
+import { Job } from '@stacksjs/queue'
+import { Storage } from '@stacksjs/storage'
+import { runTask } from '../Actions/Dashboard/Content/file-metadata'
+import { databaseMetadataStore } from '../Actions/Dashboard/Content/file-metadata-store'
+
+/**
+ * Build the responsive variants for an uploaded image (stacksjs/stacks#2578).
+ *
+ * Dispatched by the file manager's upload handler, not run inside it: encoding
+ * four widths in three formats is seconds of CPU, and an upload handler that
+ * waits for it is an upload handler that times out on a slow phone connection.
+ *
+ * Variants are written back to the SAME disk under `.variants/`, so they travel
+ * with the original and a disk that is swapped out does not leave them behind.
+ * The leading dot keeps them out of the file manager's listing, which skips
+ * hidden components - a folder of thirty derivatives beside every photo would
+ * make the browser useless.
+ *
+ * `ts-images` reads from the local filesystem, so a remote disk is staged
+ * through a temp file. That is the whole reason for the download: an S3 object
+ * has no path to hand a decoder.
+ */
+interface OptimizeStorageImagePayload {
+  disk: string
+  path: string
+}
+
+/** Where derivatives live, relative to the disk root. Hidden, so listings skip it. */
+export const VARIANT_PREFIX = '.variants'
+
+export default new Job({
+  name: 'OptimizeStorageImage',
+  description: 'Build responsive variants for an uploaded image (background)',
+  queue: 'media',
+  tries: 3,
+  backoff: [10, 30, 90],
+
+  async handle(payload: OptimizeStorageImagePayload) {
+    if (!payload?.disk || !payload?.path)
+      throw new Error('[OptimizeStorageImage] payload.disk and payload.path are required')
+
+    return await runTask(databaseMetadataStore, payload.disk, payload.path, 'optimize', async () => {
+      const adapter = Storage.disk(payload.disk)
+      const staging = await mkdtemp(join(tmpdir(), 'stacks-optimize-'))
+
+      try {
+        const source = join(staging, basename(payload.path))
+        await writeFile(source, await adapter.readToBuffer(payload.path))
+
+        const manifest = await image(source)
+          .preset('content')
+          .storage(adapter, `${VARIANT_PREFIX}/${payload.path}`)
+          .generate()
+
+        log.debug(`[OptimizeStorageImage] ${payload.path}: ${manifest.variants.length} variants`)
+
+        return {
+          variants: manifest.variants.length,
+          placeholder: manifest.placeholder,
+        }
+      }
+      finally {
+        // Always, including on the failure path: a staging directory left
+        // behind on every retry is how a worker fills its disk overnight.
+        await rm(staging, { force: true, recursive: true })
+      }
+    })
+  },
+})

package/app/Jobs/TagStorageMediaJob.ts

@@ -0,0 +1,122 @@
+import type { ConfiguredAIOptions } from '@stacksjs/ai'
+import { buildMessageWithImages, createAIClient } from '@stacksjs/ai'
+import { config } from '@stacksjs/config'
+import { log } from '@stacksjs/logging'
+import { Job } from '@stacksjs/queue'
+import { Storage } from '@stacksjs/storage'
+import { runTask, setTags } from '../Actions/Dashboard/Content/file-metadata'
+import { databaseMetadataStore } from '../Actions/Dashboard/Content/file-metadata-store'
+
+/**
+ * Ask a vision model what is in an uploaded image, and record the answer as
+ * tags (stacksjs/stacks#2578).
+ *
+ * A background job because it is a network round trip to a third party, and one
+ * that can take ten seconds under load. It also costs money per call, which is
+ * the reason for the guards below: this runs once per upload, and a retry storm
+ * against a misconfigured key would be an invoice rather than an outage.
+ *
+ * Tags are MERGED with whatever a person already put on the file rather than
+ * replacing them. A human tag is a decision and a model's tag is a suggestion,
+ * and having the suggestion overwrite the decision is the version of this
+ * feature nobody wants twice.
+ */
+interface TagStorageMediaPayload {
+  disk: string
+  path: string
+  /**
+   * How many tags to ask for. Bounded low on purpose: a model asked for twenty
+   * will produce twenty, and the last fifteen are noise that make the tag list
+   * less useful rather than more.
+   */
+  limit?: number
+}
+
+/** What the model is asked to return, so the answer is parsed rather than scraped. */
+const TAG_SCHEMA = {
+  type: 'object',
+  properties: {
+    tags: {
+      type: 'array',
+      items: { type: 'string' },
+    },
+  },
+  required: ['tags'],
+  additionalProperties: false,
+} as const
+
+const DEFAULT_LIMIT = 5
+const MAX_LIMIT = 12
+
+/** Beyond this a base64 image is a request body the provider will refuse anyway. */
+const MAX_IMAGE_BYTES = 8 * 1024 * 1024
+
+export default new Job({
+  name: 'TagStorageMedia',
+  description: 'Ask a vision model to tag an uploaded image (background)',
+  queue: 'media',
+  // Two, not three: each attempt is a paid call, and the failures worth
+  // retrying here are transient network ones rather than a rejected image.
+  tries: 2,
+  backoff: [30, 120],
+
+  async handle(payload: TagStorageMediaPayload) {
+    if (!payload?.disk || !payload?.path)
+      throw new Error('[TagStorageMedia] payload.disk and payload.path are required')
+
+    const limit = Math.max(1, Math.min(payload.limit ?? DEFAULT_LIMIT, MAX_LIMIT))
+
+    return await runTask(databaseMetadataStore, payload.disk, payload.path, 'tag', async () => {
+      const adapter = Storage.disk(payload.disk)
+      const bytes = await adapter.readToBuffer(payload.path)
+
+      if (bytes.byteLength > MAX_IMAGE_BYTES) {
+        throw new Error(
+          `[TagStorageMedia] ${payload.path} is ${bytes.byteLength} bytes; the vision path is capped at ${MAX_IMAGE_BYTES}. `
+          + 'Tag a generated variant instead of the original.',
+        )
+      }
+
+      const mediaType = await adapter.mimeType(payload.path)
+      if (!mediaType.startsWith('image/'))
+        throw new Error(`[TagStorageMedia] ${payload.path} is ${mediaType}, which is not something a vision model reads`)
+
+      const aiConfig = (config.ai || {}) as ConfiguredAIOptions
+      const client = createAIClient(aiConfig)
+
+      // Sent as base64 rather than a URL: the file may be on a private disk,
+      // and handing a provider a signed URL would mean minting one that
+      // outlives the call.
+      const content = buildMessageWithImages(
+        `Give up to ${limit} short lowercase tags describing what is in this image. `
+        + 'Prefer concrete nouns over judgements. Return only the JSON object.',
+        [{ dataBase64: bytes.toString('base64'), mediaType }],
+      )
+
+      const { data } = await client.generateObject<{ tags: string[] }>(
+        [{ role: 'user', content }],
+        TAG_SCHEMA as unknown as Record<string, unknown>,
+        { maxTokens: 300, temperature: 0 },
+      )
+
+      const suggested = Array.isArray(data?.tags) ? data.tags.slice(0, limit) : []
+      if (suggested.length === 0)
+        return { tags: [] }
+
+      // Merged, not replaced. `setTags` normalizes and deduplicates, so a model
+      // suggesting a tag somebody already applied is a no-op rather than a
+      // duplicate.
+      const existing = (await databaseMetadataStore.under(payload.disk, payload.path)).get(payload.path)
+      const record = await setTags(
+        databaseMetadataStore,
+        payload.disk,
+        payload.path,
+        [...(existing?.tags ?? []), ...suggested],
+      )
+
+      log.debug(`[TagStorageMedia] ${payload.path}: ${suggested.length} suggested, ${record.tags.length} total`)
+
+      return { tags: record.tags }
+    })
+  },
+})

package/app/Jobs/TranscodeStorageVideoJob.ts

@@ -0,0 +1,88 @@
+import { mkdtemp, rm, writeFile } from 'node:fs/promises'
+import { tmpdir } from 'node:os'
+import { basename, join } from 'node:path'
+import { log } from '@stacksjs/logging'
+import { Job } from '@stacksjs/queue'
+import { Storage } from '@stacksjs/storage'
+import { video } from '@stacksjs/video'
+import { runTask } from '../Actions/Dashboard/Content/file-metadata'
+import { databaseMetadataStore } from '../Actions/Dashboard/Content/file-metadata-store'
+import { VARIANT_PREFIX } from './OptimizeStorageImageJob'
+
+/**
+ * Transcode an uploaded video to mp4 and HLS (stacksjs/stacks#2578).
+ *
+ * #2578 asked whether video was in scope at all, on the grounds that mp4 and
+ * HLS mean ffmpeg - a heavyweight external binary, its licensing, and its
+ * provisioning across every deploy target. That question is already answered
+ * here: `@stacksjs/video` is built on `ts-videos`, which does the encoding
+ * itself, so there is no external binary to provision and no licence to take a
+ * view on. The decision the issue wanted made was made before it was written.
+ *
+ * Renditions and the HLS playlist go to the same disk under `.variants/`,
+ * alongside the image variants and hidden from the listing for the same reason.
+ *
+ * The profile has to be supplied by the caller. `ts-videos` can inspect a file,
+ * but the dashboard already knows the dimensions it needs from the upload, and
+ * a job that guesses wrong builds a ladder nobody asked for.
+ */
+interface TranscodeStorageVideoPayload {
+  disk: string
+  path: string
+  profile: Parameters<ReturnType<typeof video>['profile']>[0]
+  /** Cap the ladder at this height. Omit for every rung up to the source. */
+  maxHeight?: number
+}
+
+export default new Job({
+  name: 'TranscodeStorageVideo',
+  description: 'Transcode an uploaded video to mp4 and HLS (background)',
+  queue: 'media',
+  // Fewer tries than the image job: a transcode is minutes of CPU, and a video
+  // that fails three times is not going to succeed on a fourth.
+  tries: 2,
+  backoff: [60, 300],
+
+  async handle(payload: TranscodeStorageVideoPayload) {
+    if (!payload?.disk || !payload?.path)
+      throw new Error('[TranscodeStorageVideo] payload.disk and payload.path are required')
+    if (!payload?.profile)
+      throw new Error('[TranscodeStorageVideo] payload.profile is required - the ladder is derived from it')
+
+    return await runTask(databaseMetadataStore, payload.disk, payload.path, 'transcode', async () => {
+      const adapter = Storage.disk(payload.disk)
+      const staging = await mkdtemp(join(tmpdir(), 'stacks-transcode-'))
+
+      try {
+        const source = join(staging, basename(payload.path))
+        await writeFile(source, await adapter.readToBuffer(payload.path))
+
+        const delivery = await video(source)
+          .profile(payload.profile)
+          .ladder(payload.maxHeight ?? 'auto')
+          .output(['mp4'])
+          .streaming(['hls'])
+          .process()
+
+        // `files` is the whole delivery - renditions, playlists and segments -
+        // keyed by its path within the output. Written one at a time rather
+        // than in parallel: a transcode already saturated the box, and a
+        // hundred concurrent uploads to object storage is how the last step of
+        // a ten-minute job fails on a rate limit.
+        const prefix = `${VARIANT_PREFIX}/${payload.path}`
+        for (const [name, bytes] of Object.entries(delivery.files))
+          await adapter.write(`${prefix}/${name}`, bytes)
+
+        log.debug(`[TranscodeStorageVideo] ${payload.path}: ${Object.keys(delivery.files).length} files`)
+
+        return {
+          files: Object.keys(delivery.files).length,
+          renditions: delivery.derivatives.length,
+        }
+      }
+      finally {
+        await rm(staging, { force: true, recursive: true })
+      }
+    })
+  },
+})

package/app/Models/StorageItem.ts

@@ -0,0 +1,123 @@
+import { defineModel } from '@stacksjs/orm'
+import { schema } from '@stacksjs/validation'
+
+/**
+ * Dashboard metadata for one file on one disk (stacksjs/stacks#2577).
+ *
+ * Every file-manager operation shipped before this maps to a `StorageAdapter`
+ * method - `write`, `list`, `moveFile`, `changeVisibility`, `deleteFile`. A disk
+ * knows a path, some bytes, a size and an ACL. It does not know that somebody
+ * starred a file, and there is nowhere on a disk to write that down: extended
+ * attributes do not survive a copy and cost a syscall per file, and S3 object
+ * metadata is set at write time, so starring a 2 GB video would rewrite 2 GB.
+ * Both are a database row wearing a disguise, so this is the row.
+ *
+ * ## The disk is authoritative, this table is advisory
+ *
+ * That is the question #2577 asks to settle first, and it decides everything
+ * else. A bucket several systems write to changes without the dashboard's
+ * knowledge, so a table that claimed to describe its contents would be wrong
+ * within a day of being right. Instead:
+ *
+ * - The listing comes from the disk and is joined to these rows. A path with no
+ *   row is a file with no stars, which is the normal case and needs no row.
+ * - A row whose path no longer exists is an orphan and is simply not shown. The
+ *   listing pass already enumerates every path in the subtree, so it sweeps the
+ *   orphans it can prove are orphans - the ones under a prefix it just walked -
+ *   at no extra cost. Nothing walks the whole disk to garbage collect.
+ * - Renames and deletes made THROUGH the dashboard reconcile eagerly, so a
+ *   starred file keeps its star the moment it moves rather than waiting for a
+ *   sweep. A folder rename is a prefix update, because moving a folder moves
+ *   every file beneath it.
+ *
+ * The consequence worth stating: a file renamed outside the dashboard loses its
+ * metadata, because nothing connects the old path to the new one. That is not
+ * a gap to close later - a copy and a rename are indistinguishable to a bucket
+ * listing, so any reconciliation would be guessing.
+ *
+ * Keyed by `(disk, path)` rather than by a file id, because a disk has no file
+ * ids to key by.
+ *
+ * ## Tags are the existing vocabulary, reached the way the CMS reaches it
+ *
+ * #2577 asks for the existing vocabulary rather than a second one. That is the
+ * `tags` table, joined through the `taggable_models` pivot, with
+ * `taggable_type` keeping one model's attachments away from another's - which
+ * is what the dashboard's own tag manager writes and reads.
+ *
+ * `file-metadata-store.ts` queries it directly rather than declaring a
+ * `belongsToMany` here, because every operation is a set operation over a
+ * subtree and the relation would do them a row at a time. The relation would
+ * resolve correctly, though: `taggable_models.tag_id` is a `tags` id, which
+ * took stacksjs/stacks#2579 to establish - the migration comment and four
+ * queries in `@stacksjs/cms` said `taggables`, a different table belonging to a
+ * different mechanism.
+ */
+export default defineModel({
+  name: 'StorageItem',
+  table: 'storage_items',
+  primaryKey: 'id',
+  autoIncrement: true,
+
+  /**
+   * One row per file, enforced rather than assumed.
+   *
+   * Every write here is a get-or-create keyed on this pair, and a duplicate
+   * would not be a visible bug - it would be a file that is starred and also
+   * not starred, depending which row the query happened to read first.
+   */
+  indexes: [
+    {
+      name: 'storage_items_disk_path_unique',
+      columns: ['disk', 'path'],
+      unique: true,
+    },
+  ],
+
+  traits: {
+    useUuid: true,
+    useTimestamps: true,
+
+    useSearch: {
+      displayable: ['id', 'disk', 'path', 'favorite'],
+      searchable: ['path'],
+      sortable: ['path', 'createdAt'],
+      filterable: ['disk', 'favorite'],
+    },
+
+    useSeeder: { count: 0 },
+  },
+
+  attributes: {
+    disk: {
+      order: 1,
+      fillable: true,
+      // The disk NAME, not its driver: two disks can point at one bucket with
+      // different prefixes, and they are different namespaces to the dashboard.
+      validation: { rule: schema.string().required().min(1).max(64) },
+      factory: () => 'public',
+    },
+
+    path: {
+      order: 2,
+      fillable: true,
+      // Disk-relative and without a leading slash, exactly as the file manager
+      // reports it, so a lookup is an equality match rather than a normalization
+      // problem at every call site.
+      validation: { rule: schema.string().required().min(1).max(2048) },
+      factory: faker => `${faker.system.fileName()}`,
+    },
+
+    favorite: {
+      order: 3,
+      fillable: true,
+      default: false,
+      validation: { rule: schema.boolean() },
+      factory: () => false,
+    },
+  },
+
+  // Managed from the file manager, not as a top-level model row: a list of
+  // (disk, path, favorite) tuples is not a thing anybody wants to browse.
+  dashboard: { enabled: false },
+} as const)

package/app/Models/StorageItemTask.ts

@@ -0,0 +1,134 @@
+import { defineModel } from '@stacksjs/orm'
+import { schema } from '@stacksjs/validation'
+
+/**
+ * One unit of background processing for one file (stacksjs/stacks#2578).
+ *
+ * The three things #245 asked for that could not happen inside a request -
+ * image optimization, video transcode, AI tagging - share the same shape:
+ * dispatch work and show what happened to it. Transcoding is minutes, not
+ * milliseconds; a vision call is a round trip to a third party. An upload
+ * handler that waits for either is an upload handler that times out.
+ *
+ * ## Why this is not a column on `StorageItem`
+ *
+ * A file can have three of these at once and they succeed and fail
+ * independently - a video whose transcode finished and whose tagging failed is
+ * a normal state, and a single `processing` column cannot say it. The file
+ * manager aggregates these rows into the one word a UI shows; the rows are what
+ * a retry and an error message need.
+ *
+ * It is also keyed by `(disk, path, kind)` rather than by a `storage_items` id,
+ * deliberately. A `storage_items` row exists only while somebody has starred or
+ * tagged the file - it is deleted when it has nothing left to say - and most
+ * uploads are neither. Hanging a task off it would mean creating a metadata row
+ * for every upload just to have somewhere to put the task.
+ *
+ * Same reconciliation rules as `storage_items`, through the same store: a
+ * rename moves these rows, a delete forgets them, and a completed listing
+ * sweeps the ones whose file is gone.
+ */
+export default defineModel({
+  name: 'StorageItemTask',
+  table: 'storage_item_tasks',
+  primaryKey: 'id',
+  autoIncrement: true,
+
+  /**
+   * One task per kind per file.
+   *
+   * Re-running replaces the row rather than adding a second, so "what happened
+   * to the transcode" has one answer. The history of previous attempts is the
+   * queue's to keep, not this table's.
+   */
+  indexes: [
+    {
+      name: 'storage_item_tasks_disk_path_kind_unique',
+      columns: ['disk', 'path', 'kind'],
+      unique: true,
+    },
+  ],
+
+  traits: {
+    useUuid: true,
+    useTimestamps: true,
+
+    useSearch: {
+      displayable: ['id', 'disk', 'path', 'kind', 'state'],
+      searchable: ['path'],
+      sortable: ['path', 'createdAt'],
+      filterable: ['disk', 'kind', 'state'],
+    },
+
+    useSeeder: { count: 0 },
+  },
+
+  attributes: {
+    disk: {
+      order: 1,
+      fillable: true,
+      validation: { rule: schema.string().required().min(1).max(64) },
+      factory: () => 'public',
+    },
+
+    path: {
+      order: 2,
+      fillable: true,
+      validation: { rule: schema.string().required().min(1).max(2048) },
+      factory: faker => faker.system.fileName(),
+    },
+
+    kind: {
+      order: 3,
+      fillable: true,
+      // `optimize` (images), `transcode` (video), `tag` (AI). An enum rather
+      // than free text so a typo in a dispatch is a validation error instead of
+      // a task nothing will ever run.
+      validation: { rule: schema.enum(['optimize', 'transcode', 'tag']) },
+      factory: () => 'optimize',
+    },
+
+    state: {
+      order: 4,
+      fillable: true,
+      default: 'queued',
+      validation: { rule: schema.enum(['queued', 'running', 'done', 'failed']) },
+      factory: () => 'queued',
+    },
+
+    attempts: {
+      order: 5,
+      fillable: true,
+      default: 0,
+      // Counted here as well as in the queue, because the queue's count is gone
+      // once the job leaves it and this is what the dashboard reads.
+      validation: { rule: schema.number() },
+      factory: () => 0,
+    },
+
+    error: {
+      order: 6,
+      fillable: true,
+      // The failure as the worker saw it. Truncated by the writer rather than
+      // by the column, so a stack trace does not silently lose its first line.
+      validation: { rule: schema.string().max(2000) },
+      factory: () => '',
+    },
+
+    startedAt: {
+      order: 7,
+      fillable: true,
+      validation: { rule: schema.string() },
+      factory: () => '',
+    },
+
+    finishedAt: {
+      order: 8,
+      fillable: true,
+      validation: { rule: schema.string() },
+      factory: () => '',
+    },
+  },
+
+  dashboard: { enabled: false },
+} as const)

package/ide/vscode/package.json

@@ -2,7 +2,7 @@
   "publisher": "Stacks",
   "name": "vscode-stacks",
   "displayName": "Stacks",
-  "version": "0.74.33",
+  "version": "0.74.35",
   "description": "A modern Stacks development environment.",
   "license": "MIT",
   "funding": "https://github.com/sponsors/chrisbbreuer",

package/package.json

@@ -2,7 +2,7 @@
   "name": "@stacksjs/defaults",
   "type": "module",
   "sideEffects": false,
-  "version": "0.74.33",
+  "version": "0.74.35",
   "repository": {
     "type": "git",
     "url": "git+https://github.com/stacksjs/stacks.git",
@@ -55,7 +55,7 @@
   "dependencies": {
     "@iconify-json/f7": "^1.2.2",
     "@iconify-json/hugeicons": "^1.2.27",
-    "@stacksjs/mobile": "^0.74.33",
+    "@stacksjs/mobile": "^0.74.35",
     "@stacksjs/sanitizer": "^0.2.113",
     "ts-qr-codes": "^0.1.8"
   }