feat: support verb overrides for json and object meta data#183
Conversation
🦋 Changeset detectedLatest commit: 22d2293 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
WalkthroughThis pull request introduces support for HTTP verb-specific overrides in JSON and object metadata files for Marko Run routes. The type system is enhanced to track HTTP verbs throughout request handling, with Context and Handler types now parameterized by verb. A new metadata normalization system merges verb-specific keys (GET, POST, etc.) with base metadata properties based on the current request method. Test fixtures demonstrate both JSON and JavaScript-based meta files supporting verb-specific metadata structures. Generated route type declarations now expose per-verb handler type aliases for GET, HEAD, POST, PUT, DELETE, PATCH, and OPTIONS. The runtime handler normalization pipeline is updated to include metadata normalization alongside handler wrapping. 🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
🧪 Generate unit tests (beta)
Tip Issue Planner is now in beta. Read the docs and try it out! Share your feedback on Discord. Comment |
There was a problem hiding this comment.
Actionable comments posted: 5
🤖 Fix all issues with AI agents
In @.gitignore:
- Line 10: The .gitignore currently has the rule for "*.actual.*" commented out
(line showing "# *.actual.*"); decide whether these generated/fixture artifact
files should be tracked—if they should remain ignored, uncomment the rule so
"*.actual.*" stays excluded; if specific actual.* outputs must be committed for
a subdirectory, replace the blanket rule with a scoped exception or explicit
allow-list for that directory instead of re-adding a global tracked pattern to
avoid repo bloat.
In `@packages/run/README.md`:
- Around line 210-251: Fix typos and make the +meta examples valid JSON/JS:
correct misspellings like "exlcuded" → "excluded", ensure JSON objects use
proper commas and quoted keys/strings, and make the examples consistent (use
"postOnlyData" everywhere and fix "portOnlyData" typo). Update the JSON example
for +meta.json to include commas and quoted keys/strings, ensure the GET/POST
nested objects are valid objects, and keep the PUT value as a non-object example
to demonstrate it being ignored; reference the +meta.json example and the
resulting context.meta outputs so those code blocks compile and match the text.
In `@packages/run/src/runtime/types.ts`:
- Line 251: The empty AppData interface is intentional for declaration merging;
add a Biome lint suppression above the declaration to silence the
noEmptyInterface rule (e.g., add a single-line comment like "biome-ignore
noEmptyInterface" immediately above export interface AppData {}) so the intent
is documented and the linter won't flag the empty interface used for
augmentation via declare module "@marko/run".
In `@packages/run/src/vite/codegen/index.ts`:
- Around line 159-176: The current code builds metaVerbsExports by remapping
HEAD to GET when there is no explicit HEAD handler, which prevents a +meta HEAD
override from being exported; change the logic that composes metaVerbsExports so
HEAD is always included (i.e., always destructure a HEAD entry like "HEAD:
head{index}_meta") instead of conditionally mapping it to GET, and rely on
normalizeMeta (or a later normalization step) to apply any GET fallback; update
references in this block using metaName, metaVerbsExports, verbs, handler, and
normalizeMeta so the writer still imports metaName and exports the destructured
verbs but with HEAD explicitly present.
In `@packages/run/src/vite/utils/meta-data.ts`:
- Around line 14-18: The function getMetaDataForVerb currently erases
verb-specific return types; change its signature to be generic over a concrete
verb (e.g., add a type parameter V extends Verb and accept verb: V) and make the
return type NormalizedMeta<T, V> so callers retain narrowing; keep the existing
runtime check against httpVerbs but adapt any casts to satisfy the compiler
(refer to getMetaDataForVerb, Verb, NormalizedMeta, and httpVerbs) so the
implementation still validates the verb while the signature preserves
verb-specific typing.
84e1e1c to
22d2293
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In
`@packages/run/src/__tests__/fixtures/verb-specific-json-meta-fallback/src/routes/`+meta.json:
- Around line 1-10: The "get" key in the JSON will not be treated as a verb
override because overrides are matched by uppercase HTTP verbs; update the key
"get" to "GET" if you intended a GET-specific override (e.g., change the "get"
object to "GET"), or rename the "get" property to a non-verb name (e.g.,
"getMeta" or "otherGet") if it should remain part of base meta so it doesn't get
mistaken for an override alongside "POST" and "pageTitle".
packages/run/src/__tests__/fixtures/verb-specific-json-meta-fallback/src/routes/+meta.json
Show resolved
Hide resolved
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #183 +/- ##
===========================
===========================
☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Description
Adds support for HTTP verb/method specific overrides to meta data defined in
+meta.*files.For meta files which export an object, including JSON files, top-level keys which match HTTP verbs (uppercase) will be considered overrides. These overrides are excluded from the meta data object on context and one matching the current request method, will be merged shallowly into the base meta data object replacing any existing values.
More information and and example is in the README.