brevo-api: Fix unresolvable src/... imports in the published type declarations

[VPS-Obi]

Some brevo-api sources imported internal types via bare src/... specifiers. They only resolved inside the package (through baseUrl) and were emitted unchanged into the published .d.ts files. Consuming projects can't resolve them, so these types silently became any, for instance EmailCampaignScopeInterface and large parts of the BrevoModule.register() config. The imports are now relative, and baseUrl is gone so that bare src/... imports fail to compile.

Once the types resolve, the scope callbacks in the config reject the application's own scope class under strictFunctionTypes: (scope: EmailCampaignContentScope) => ... isn't assignable to (scope: Record<string, any>) => .... To fix this, BrevoModuleConfig is now generic over the scope type, and BrevoModule.register() infers it from emailCampaigns.Scope. This way brevo.resolveConfig and emailCampaigns.frontend can be typed with the application's scope class without casts:

BrevoModule.register({
    brevo: {
        resolveConfig: (scope: EmailCampaignContentScope) => {
            /* ... */
        },
        // ...
    },
    emailCampaigns: {
        Scope: EmailCampaignContentScope,
        frontend: (scope: EmailCampaignContentScope) => {
            /* ... */
        },
        // ...
    },
});

The type parameter has a default, so existing references to BrevoModuleConfig keep working. Projects whose config was only accepted because it was typed as any may now get type errors.

Session: https://claude.ai/code/session_01PJLvtQHLoB2B8Qsfxvo9Pw

[VPS-Obi]

@greptileai review

---

Generated by Claude Code

[greptile-apps]

Confidence Score: 4/5

The PR should satisfy the repository’s binding import convention before merging.

Findings

1.  Cross-module relative imports ▶

Summary

The PR replaces bare src/... imports with relative imports and makes the Brevo configuration generic over the application’s campaign scope.

• The previously reviewed consumer-coverage concern was resolved after the author explained the existing build and demo type-check coverage.
• The converted cross-module imports conflict with the repository’s binding TypeScript import convention.

_{Reviews (3) · Last reviewed commit: "brevo-api: Use relative imports so publi..."}

[VPS-Obi]

Replies to the Greptile findings (both non-blocking):

1. Published types lack consumer coverage: won't add it in this PR. Removing baseUrl means a bare src/... import no longer compiles in the package build, which already prevents this regression. demo/api's lint:tsc also type-checks BrevoModule.register() against the built declarations.
2. Metadata discovery lacks test coverage: blocks-meta.service.ts isn't part of this PR. The review looks like it ran against the pre-retarget base and picked up commits that are already on next.

---

Generated by Claude Code

[greptile-apps]

Comments Outside Diff

These findings sit on lines the diff does not cover, so they could not be posted inline. Each one leaves this list once its file changes.

•  Metadata discovery lacks test coverage. packages/api/cms-api/src/blocks/blocks-meta.service.ts:26 ▶

  Production now discovers root blocks before generating block-meta.json, while the new tests pass root blocks directly to the traversal function. If discovery misses a root, those tests can still pass while the written metadata is incomplete. A service-level test of discovery through file generation would cover that gap.

  Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!