fix: Support @contentType for multiline values

[SrsDanny]

Description

Fixes #5767, where the @contentType annotation caused parsing issues for multiline values.

I updated the existing multilinetextblock rule so it can optionally parse a trailing @contentType annotation. This annotation is appended to the end of the value and later extracted by multipartExtractContentType.

An alternative would be to add a dedicated dictionary-like grammar element specifically for body:multipart-form, since @contentType with multiline values only makes sense there. However, that approach would require a larger grammar and semantic change.

Contribution Checklist:

• The pull request only addresses one issue or adds one feature.
• The pull request does not introduce any breaking changes
• I have added screenshots or gifs to help explain the change if applicable.
• I have read the contribution guidelines.
• Create an issue and link to the pull request.

Note: Keeping the PR small and focused helps make it easier to review and merge. If you have multiple changes you want to make, please consider submitting them as separate pull requests.

Publishing to New Package Managers

Please see here for more information.

Summary by CodeRabbit

• New Features

  • Multiline text blocks now support optional content-type annotations and will include declared content type in parsed results.
  • Value parsing updated to better handle single-line values alongside multiline blocks.

• Tests

  • Added test coverage and updated test collections demonstrating multipart bodies with content-type-annotated multiline fields.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[SrsDanny]

The linter is failing on files that I didn’t modify in this PR, even though npm run lint passes locally.

Could you confirm if the CI environment uses a different linter configuration or Node version? Should I fix those unrelated files?

[coderabbitai]

Walkthrough

Adds support for an inline content-type annotation @contentType(...) for Bru multiline text blocks, updates grammar and semantics to surface contentType for multipart/form fields, and includes tests plus an example demonstrating parsing and round-trip verification.

Changes

Cohort / File(s)	Summary
Grammar & Parser Logic packages/bruno-lang/v2/src/bruToJson.js	Extended multilinetextblock to accept optional st* contenttypeannotation?; added contenttypeannotation and singlelinevalue rules; replaced previous value(chars) branching with explicit singlelinevalue; semantics updated to accept and append contentType source string to multiline content when present; enabled dotAll (s) mode in content-type regex handling.
Test Coverage packages/bruno-lang/v2/tests/bruToJson.spec.js	Added test: "parses multiline body parts with content type annotation" verifying a multipart filePart with @contentType(application/json) is parsed into an object containing name, value (joined lines), enabled, type, and contentType.
Example Collection packages/bruno-tests/collection/echo/echo multipart.bru	Added a multipart form field using a JSON multiline block annotated with @contentType(application/json) and updated assertions to verify the response includes the annotated Content-Type.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

• Review grammar changes for backward compatibility with existing multiline blocks and single-line values (singlelinevalue).
• Validate content-type parsing regex (dotAll/s flag) and edge cases (nested/malformed parentheses, escaping).
• Inspect semantics: ensure indentation stripping, line joining, and conditional appending of contentType.sourceString are correct and robust.
• Verify tests and example match runtime behavior for multipart serialization/emission.

Poem

Multiline blocks now wear a sign,
A tiny tag to mark their kind.
From parser depths a signal gleams,
Content types flow into dreams. ✨

Pre-merge checks and finishing touches

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and concisely describes the main change: adding support for @ContentType annotation for multiline values in the Bru language parser.
Linked Issues check	✅ Passed	The PR implements the requirements from issue #5767: parsing and preserving @ContentType annotations for multiline form values to prevent request loss when reopening collections.
Out of Scope Changes check	✅ Passed	All changes are focused on the stated objective: grammar/semantics updates for multiline content-type support, corresponding tests, and a demo collection file.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[SrsDanny]

Alright, rebasing onto the latest main fixed the lint issues.

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (2)

packages/bruno-lang/v2/src/bruToJson.js (2)

55-57: Multiline ''' blocks with @contentType look correct; consider improving indentation handling and trimming

The grammar + semantics for multilinetextblock and singlelinevalue line up well with the multipart @contentType(...) pipeline and fix the original bug: multiline values now carry the annotation through to multipartExtractContentType.

Two optional refinements you might consider:

• Instead of hard‑coding line.slice(4) in multilinetextblock, reuse outdentString or a minIndent style approach (as in parseExampleContent) to avoid stripping real content if indentation is not exactly 4 spaces or includes tabs.
• Since pair() already does value.ast.trim(), singlelinevalue could just return chars.sourceString || '' and let the trim happen in one place, unless you explicitly want trimming at this layer too.

Also applies to: 69-71, 422-435

---

214-229: Unify @contentType regex and align trimming behavior between multipart and file

Both multipartExtractContentType and fileExtractContentType now use the same pattern /^(.*?)\s*@contentType\((.*?)\)\s*$/s, which is good. Right now though:

• The regex literal is duplicated in two places.
• fileExtractContentType trims both match[1] and match[2], while multipartExtractContentType leaves them as‑is, which can lead to subtle differences if someone writes extra spaces inside the annotation.

To keep behavior consistent and easier to maintain, you could:

• Factor the regex into a shared constant (e.g. CONTENT_TYPE_ANNOTATION_RE) and reuse it in both helpers.
• Decide whether you always want to normalize contentType (and possibly value) with .trim() in both helpers, or keep raw spacing intentionally — and implement that choice uniformly.

📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between d918696 and 047defc.

📒 Files selected for processing (1)

• packages/bruno-lang/v2/src/bruToJson.js (5 hunks)