feat: Add Call type for Vim/Neovim function call representation

[Milly]

Summary

This PR introduces a new Call type to represent Vim/Neovim function call tuples, improving type reusability and code
maintainability.

Motivation

Currently, every method that uses function call tuples needs to redefine the tuple type [string, ...unknown[]] inline. This
approach violates the DRY (Don't Repeat Yourself) principle and leads to:

• Type duplication: The same tuple structure is redefined multiple times across the codebase
• Inconsistency risks: Different implementations might define slightly different tuple types
• Reduced maintainability: Changes to the tuple structure would require updates in multiple locations

In practice, we already see this issue in the ecosystem:

• @denops/std/batch and other modules redefine similar tuple types
• Each implementation creates its own version of essentially the same type

Changes

• Added Call type definition
• Updated batch method signature to use the Call type
• Improved JSDoc comments for clarity
  • Note: JSDoc does not support @param tags for labeled tuple elements, so fn and args are documented as regular text descriptions

Compatibility

This change is fully backward compatible:

• The Call type is simply an extraction of the existing tuple structure
• No runtime behavior changes
• No breaking changes to the API
• Existing code continues to work without modifications
• The type signature remains exactly the same

This aligns with the @denops/core philosophy of maintaining stability while improving developer experience.

Future Plans

Once this change is merged, we plan to:

1. Re-export the Call type from @denops/std for plugin developers

• Plugin developers will import from @denops/std (following the principle that @denops/core is not directly used by plugin
  developers)
• This will provide a single, canonical type for function calls across the ecosystem

2. Update existing modules in @denops/std to use this type, eliminating duplications

Benefits

1. Better DX: Developers can import and reuse the Call type (via @denops/std)
2. Type consistency: Single source of truth for function call tuple type
3. Improved maintainability: Future changes to the call structure only need updates in one place
4. Documentation: The type itself serves as documentation for what a "call" represents
5. Ecosystem alignment: Provides a foundation for consistent type usage across denops libraries

Testing

• Type-only change, no runtime impact
• Existing tests continue to pass
• TypeScript compiler validates the type compatibility

Summary by CodeRabbit

• Refactor
  • Refined batch method API signature for improved consistency and type clarity in function invocations.

[coderabbitai]

Walkthrough

A new Call type is introduced to represent Vim/Neovim function invocations as tuples with function names and variadic arguments. The Denops.batch method signature is updated to use this Call type instead of inline tuple types, standardizing the function call representation.

Changes

Cohort / File(s)	Summary
Type definition and method signature updates type.ts	Adds exported Call type [fn: string, ...args: unknown[]] for function invocations; updates Denops.batch method signature to use Call[] instead of [string, ...unknown[]][] for type consistency

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

Poem

🐰 A type called Call hops into sight,
Standardizing function invocations just right,
batch now speaks in clearer tongue,
With Call types strong and freshly sung! ✨

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title Check	✅ Passed	The PR title "feat: Add Call type for Vim/Neovim function call representation" accurately and directly describes the main change in the pull request. The changeset introduces a new exported Call type to represent Vim/Neovim function invocations and updates the Denops.batch method signature to use this type. The title is concise, uses clear language without vague terms or noise, and follows conventional commit format with the "feat:" prefix. A teammate scanning the repository history would immediately understand that this PR adds a type definition for function call representation.
Docstring Coverage	✅ Passed	No functions found in the changes. Docstring coverage check skipped.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch add-call-type

---

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between fd101cc and 7eeb578.

📒 Files selected for processing (1)

• type.ts (2 hunks)

🔇 Additional comments (2)

type.ts (2)

22-28: LGTM! Excellent type definition.

The Call type is well-defined with labeled tuple elements that make the code self-documenting. The JSDoc appropriately documents the components in plain text, which is the right approach given that JSDoc cannot tag labeled tuple elements. This addition improves type consistency and reusability across the codebase.

---

149-153: LGTM! Backward-compatible signature improvement.

The batch method signature correctly uses the new Call type, and the JSDoc clearly documents the parameter structure. This change is fully backward compatible since Call is structurally equivalent to the previous inline tuple type [string, ...unknown[]]. The labeled tuple elements in the Call type enhance readability without affecting type compatibility.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

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

[lambdalisue]

LGTM