development-only-lovable-tagger: Development-only Lovable tagger #3
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "task/development-only-lovable-tagger"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Assigned idea
Benchmark authoring specification.
Summary: Refactor the Vite config so production/Cloudflare builds do not load the Lovable development tagger package, while development mode still enables it.
Task intent: Make ordinary upstream-facing maintenance to
vite.config.ts: keep the React SWC plugin,@alias, dev server settings, and Cloudflaredistoutput, but ensurelovable-taggeris imported and used only whenmode === 'development'.Benchmark plan: Construct a regular coding task from the fixed repo commit that asks the solver to update only the Vite configuration. The prompt should state that production config loading must succeed even if
lovable-taggeris unavailable, and development mode must still include the component tagger. Keep the package focused on repo behavior invite.config.ts; put all checks in an externaltest_outputs.py.Environment plan: Task environment: Node.js 20+, npm-installed repo dependencies, and Python 3 for the verifier; no browser or Cloudflare account is needed. Repo environment: use the materialized checkout at the specified commit and load
vite.config.tsthrough Vite’s config loader under production and development modes, temporarily hidingnode_modules/lovable-taggeronly for the production-mode check.Verifier plan:
test_outputs.pyshould readvite.config.tsand assert there is no static import fromlovable-tagger, while a dynamicimport('lovable-tagger')or equivalent development-only dynamic import remains. It should create.verifier/load-vite-config.mjsthat calls ViteloadConfigFromFileforvite.config.ts. The verifier should temporarily renamenode_modules/lovable-taggerif present, runnode .verifier/load-vite-config.mjs production, and assert the config loads withbuild.outDir === 'dist',server.host === '::',server.port === 8080, and an@alias ending in/src. It should restore the package, runnode .verifier/load-vite-config.mjs development, and assert the development plugin list has more flattened plugin entries than production.Oracle plan: The oracle solution removes the top-level
import { componentTagger } from 'lovable-tagger', makes thedefineConfigcallback async, builds a plugins array starting withreact(), dynamically importslovable-taggeronly inside themode === 'development'branch, pushescomponentTagger()there, and returns the existing server, resolve alias, and buildoutDir: 'dist'settings unchanged.Difficulty plan: Current coding agents may see the existing
mode === 'development' && componentTagger()expression and miss that the top-level import still loads the package in production. Others may delete the tagger entirely, break the async Vite config shape, forget to preserve.filter(Boolean)-style plugin handling, or accidentally alter the alias/build settings while refactoring.Repo patch scope: Expected upstream edits are limited to
vite.config.ts. Do not changesrc/, package manifests, lockfiles, generateddist, or unrelated configuration.Anti-leakage notes: The solver-facing prompt must not mention benchmark, harness, Snorkel, Harbor, std-ts, agent, stage, attempt, retry, generated task, or evaluation context.
Approach: Implement a development-only dynamic import in
vite.config.tsand keep all other existing Vite settings semantically identical.Verification: From the repo root, run
npm installand thenpython test_outputs.py; the verifier runsnode .verifier/load-vite-config.mjs productionwithnode_modules/lovable-taggerhidden andnode .verifier/load-vite-config.mjs developmentafter restoring it.Risk: Low scope risk because the behavior is isolated to Vite config loading. Main verifier risk is dependency layout when hiding
node_modules/lovable-tagger; mitigate by restoring it in afinallyblock and using the Vite config API rather than a full browser build.Path rules: task package is tasks/; mutable upstream checkout is tasks//environment/repo; benchmark package files are under tasks//task; verifier/container environment belongs under tasks//task/environment; regular and UI verifier logic belongs in task/tests/test_outputs.py and test.sh only runs that file through pytest.
Agent context
Task slug: development-only-lovable-tagger
Branch: task/development-only-lovable-tagger
View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.Merge
Merge the changes and update on Forgejo.Warning: The "Autodetect manual merge" setting is not enabled for this repository, you will have to mark this pull request as manually merged afterwards.