Skip to content

Conversation

@babu-ch
Copy link
Contributor

@babu-ch babu-ch commented Aug 24, 2025

close #1517

Summary by CodeRabbit

  • New Features

    • Config exports can now be provided as objects, promises, functions, or async functions; loader and validator accept and resolve all forms.
  • Tests

    • Added tests and fixtures verifying loading and validation for object-, promise-, function-, and async-function-based configs.
  • Chores

    • Added a changeset marking a patch release documenting the expanded config input support.

Checklist

  • Tests updated (or not required).
  • Documentation updated (or not required).
  • Changeset added, and when a BREAKING CHANGE occurs, it needs to be clearly marked (or not required).

@babu-ch babu-ch requested a review from colinaaa as a code owner August 24, 2025 06:59
@coderabbitai
Copy link
Contributor

coderabbitai bot commented Aug 24, 2025

📝 Walkthrough

Walkthrough

Adds support for config exports that are Promise, function, or function-returning-Promise by introducing a ConfigExport type, extending defineConfig overloads, updating validation and loader to accept/invoke/await those shapes, and adding tests, fixtures, and a changeset.

Changes

Cohort / File(s) Summary
Config typings & defineConfig
packages/rspeedy/core/src/config/defineConfig.ts
Add ConfigExport type and overloads so defineConfig accepts Config, Promise<Config>, () => Config, and () => Promise<Config>; implementation returns input unchanged.
Validation
packages/rspeedy/core/src/config/validate.ts
Switch typia validation target and exported validate signature from Config to ConfigExport.
Loader behavior
packages/rspeedy/core/src/config/loadConfig.ts
Resolve validated content that may be a function or promise: invoke function-exports and await promises; error handling and unregister flow unchanged.
Tests & fixtures
packages/rspeedy/core/test/config/loadConfig.test.ts, packages/rspeedy/core/test/config/validate.test.ts, packages/rspeedy/core/test/config/fixtures/custom/*, packages/rspeedy/core/test/config/defineConfig.test-d.ts
Add fixtures (function.ts, promise.ts, function-promise.ts) and tests covering object, function, promise, and function-promise config loading and validation; update type tests to use ConfigExport.
Changeset & API doc
.changeset/small-rivers-arrive.md, packages/rspeedy/core/etc/rspeedy.api.md
Add changeset marking a patch release and update API docs to include new defineConfig overloads.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Assessment against linked issues

Objective Addressed Explanation
Support Promise<Config> export form [#1517]
Support () => Config and () => Promise<Config> export forms [#1517]

Suggested reviewers

  • upupming
  • gaoachao

Poem

I'm a rabbit with a config in paw,
Promises, functions—I'll fetch them all, hurrah!
I call, I await, I keep types snug and neat,
Fixtures hop in, tests pass on tiny feet. 🐇✨

Tip

🔌 Remote MCP (Model Context Protocol) integration is now available!

Pro plan users can now connect to remote MCP servers from the Integrations page. Connect with popular remote MCPs such as Notion and Linear to add more context to your reviews and chats.

✨ Finishing Touches
  • 📝 Generate Docstrings
🧪 Generate unit tests
  • Create PR with unit tests
  • Post copyable unit tests in a comment

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
🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.

Support

Need help? Create a ticket on our support page for assistance with any issues or questions.

CodeRabbit Commands (Invoked using PR/Issue comments)

Type @coderabbitai help to get the list of available commands.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

Status, Documentation and Community

  • Visit our Status Page to check the current availability of CodeRabbit.
  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

@changeset-bot
Copy link

changeset-bot bot commented Aug 24, 2025

🦋 Changeset detected

Latest commit: ee54795

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 3 packages
Name Type
@lynx-js/rspeedy Patch
create-rspeedy Patch
upgrade-rspeedy Patch

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

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🧹 Nitpick comments (6)
.changeset/small-rivers-arrive.md (1)

5-5: Polish the changeset message (casing/punctuation).

Align with common style used in the repo by adding a colon and using sentence casing.

-rspeedy Support Promise and function in defineConfig
+rspeedy: support Promise and function in defineConfig
packages/rspeedy/core/test/config/loadConfig.test.ts (1)

313-342: Great coverage for function/promise wrappers; add negative cases to prove post-resolution validation.

These tests confirm happy paths. Add failure-path tests where the function/promise returns an invalid config to ensure loadConfig throws after re-validation.

You can add tests without new fixtures by creating temp files:

@@
   test('load function-promise config', async () => {
@@
   })
+
+  test('load invalid function config should fail validation', async () => {
+    const cwd = await mkdtemp(join(tmpdir(), 'rspeedy-test-invalid-func'))
+    await writeFile(
+      join(cwd, 'invalid-function.ts'),
+      `export default () => ({ unknown: 1 })`,
+    )
+    await expect(
+      loadConfig({ cwd, configPath: './invalid-function.ts' }),
+    ).rejects.toThrowError(
+      /Unknown property: `\$input\.unknown` in configuration/,
+    )
+  })
+
+  test('load invalid promise config should fail validation', async () => {
+    const cwd = await mkdtemp(join(tmpdir(), 'rspeedy-test-invalid-promise'))
+    await writeFile(
+      join(cwd, 'invalid-promise.ts'),
+      `export default Promise.resolve({ unknown: 1 })`,
+    )
+    await expect(
+      loadConfig({ cwd, configPath: './invalid-promise.ts' }),
+    ).rejects.toThrowError(
+      /Unknown property: `\$input\.unknown` in configuration/,
+    )
+  })
packages/rspeedy/core/src/config/validate.ts (1)

8-16: Expose a strongly-typed validator for resolved Config to avoid downstream casts.

validate now returns ConfigExport, which is perfect for pre-resolution checks. After we resolve the value in loadConfig, we need a Config-only validator to avoid as Config casts and make intent explicit.

As a follow-up, consider adding a dedicated API:

 import * as typia from 'typia'
 
-import type { ConfigExport } from './defineConfig.js'
+import type { Config } from './index.js'
+import type { ConfigExport } from './defineConfig.js'
@@
 export const validateConfig: (
   input: unknown,
 ) => typia.IValidation<ConfigExport> = typia.createValidateEquals<
   ConfigExport
 >()
 
+export const validateResolvedConfig: (
+  input: unknown,
+) => typia.IValidation<Config> = typia.createValidateEquals<Config>()
+
 export function validate(input: unknown, configPath?: string): ConfigExport {
@@
 }
+
+export function assertConfigObject(
+  input: unknown,
+  configPath?: string,
+): Config {
+  const result = validateResolvedConfig(input)
+  if (result.success) return result.data
+
+  const messages = result.errors.flatMap(({ expected, path, value }) => {
+    if (expected === 'undefined') {
+      return [`Unknown property: \`${color.red(path)}\` in configuration`, '']
+    }
+    return [
+      `Invalid config on \`${color.red(path)}\`.`,
+      `  - Expect to be ${color.green(expected)}`,
+      `  - Got: ${color.red(whatIs(value))}`,
+      '',
+    ]
+  })
+  throw new Error(
+    [
+      `Invalid configuration${
+        configPath ? ` loaded from ${color.dim(configPath)}` : '.'
+      }`,
+      '',
+    ]
+      .concat(messages)
+      .join('\n'),
+  )
+}

Then loadConfig can call assertConfigObject(resolved, configPath) instead of reusing validate + cast.

packages/rspeedy/core/src/config/defineConfig.ts (3)

27-31: Prefer an Awaitable-based union and PromiseLike for broader interop.

Using PromiseLike allows thenables (not only native Promise). Collapsing the four-way union into “awaitable or function returning awaitable” simplifies the surface while remaining source-compatible.

Apply this diff to simplify and generalize:

-export type ConfigExport =
-  | Config
-  | Promise<Config>
-  | (() => Config)
-  | (() => Promise<Config>)
+/** @public
+ * Input shape accepted by defineConfig. Thenables are supported via PromiseLike.
+ */
+export type Awaitable<T> = T | PromiseLike<T>
+export type ConfigExport = Awaitable<Config> | (() => Awaitable<Config>)

32-40: Collapse overloads into a single generic to preserve exact types and reduce maintenance.

A single generic overload returns the precise input type (identity) and avoids duplication. The implementation signature remains the broad union.

Apply this diff:

-export function defineConfig(config: Config): Config
-export function defineConfig(config: () => Config): () => Config
-export function defineConfig(config: Promise<Config>): Promise<Config>
-export function defineConfig(
-  config: () => Promise<Config>,
-): () => Promise<Config>
-export function defineConfig(
-  config: ConfigExport,
-): ConfigExport {
+export function defineConfig<T extends ConfigExport>(config: T): T
+export function defineConfig(config: ConfigExport): ConfigExport {
   return config
 }

Notes:

  • Keeps the identity semantics while retaining literal inference on the config object (nice for enums/const unions inside Config).
  • No runtime change; emits the same JS.

27-31: Add a short JSDoc on the exported type for API docs completeness.

Since ConfigExport is now public, a brief TSDoc makes it visible and clear in generated docs.

Example:

/** Union of config shapes accepted by defineConfig: a Config (or thenable), or a function returning one. */
export type ConfigExport = ...
📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

💡 Knowledge Base configuration:

  • MCP integration is disabled by default for public repositories
  • Jira integration is disabled by default for public repositories
  • Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

📥 Commits

Reviewing files that changed from the base of the PR and between 52db511 and 1644c88.

📒 Files selected for processing (6)
  • .changeset/small-rivers-arrive.md (1 hunks)
  • packages/rspeedy/core/src/config/defineConfig.ts (1 hunks)
  • packages/rspeedy/core/src/config/loadConfig.ts (1 hunks)
  • packages/rspeedy/core/src/config/validate.ts (1 hunks)
  • packages/rspeedy/core/test/config/loadConfig.test.ts (1 hunks)
  • packages/rspeedy/core/test/config/validate.test.ts (1 hunks)
🧰 Additional context used
🧬 Code graph analysis (3)
packages/rspeedy/core/test/config/validate.test.ts (1)
packages/rspeedy/core/src/config/validate.ts (1)
  • validate (16-48)
packages/rspeedy/core/test/config/loadConfig.test.ts (1)
packages/rspeedy/core/src/config/loadConfig.ts (1)
  • loadConfig (107-157)
packages/rspeedy/core/src/config/validate.ts (1)
packages/rspeedy/core/src/config/defineConfig.ts (1)
  • ConfigExport (27-31)
🪛 LanguageTool
.changeset/small-rivers-arrive.md

[grammar] ~4-~4: Ensure spelling is correct
Context: --- "@lynx-js/rspeedy": minor --- rspeedy Support Promise and function in defineC...

(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)


[grammar] ~5-~5: There might be a mistake here.
Context: ...ort Promise and function in defineConfig

(QB_NEW_EN)

🔇 Additional comments (3)
packages/rspeedy/core/test/config/validate.test.ts (1)

46-57: LGTM; covers the new wrapper shapes.

This verifies validate accepts and returns the wrapper unchanged, which is correct for the pre-resolution phase.

To guard against regressions from the fix in loadConfig, consider adding complementary tests in the loadConfig suite that ensure invalid configs wrapped in a function/promise are rejected after resolution (e.g., export default () => ({ unknown: 1 }) should throw).

packages/rspeedy/core/src/config/defineConfig.ts (2)

27-41: Solid API surface for “function” and “promise” config inputs.

The exported union plus overloads achieve the goal of accepting Config, Promise, function, and async function forms while keeping defineConfig an identity at runtime. This aligns with how loaders can later resolve/await as needed. No correctness issues spotted here.


33-37: Clarify and Align defineConfig(Promise<Config>) Semantics

The current overloads in packages/rspeedy/core/src/config/defineConfig.ts (lines 32–37) treat a Promise<Config> input as an identity, returning Promise<Config>—not unwrapping it to Config as the examples in Issue #1517 imply. Since you can’t synchronously resolve a promise, resolution must occur later in loadConfig.

Please ensure that:

  • The documentation/examples in Issue #1517 (and any JSDoc) are updated to show
    defineConfig(Promise<Config>): Promise<Config>
    and include a note that promise inputs are not unwrapped by defineConfig itself.
  • A short JSDoc comment is added above defineConfig clarifying it passes through Promise inputs directly.
  • The loadConfig implementation (in packages/rspeedy/core/src/config/loadConfig.ts) correctly awaits or invokes the exported config—i.e., that promise inputs are resolved at load time.

Copy link
Collaborator

@colinaaa colinaaa left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you!

@codecov
Copy link

codecov bot commented Aug 25, 2025

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ All tests successful. No failed tests found.

📢 Thoughts on this report? Let us know!

@relativeci
Copy link

relativeci bot commented Aug 25, 2025

Web Explorer

#4539 Bundle Size — 366.68KiB (0%).

71675e3(current) vs 1cbccc1 main#4527(baseline)

Bundle metrics  no changes
                 Current
#4539
     Baseline
#4527
No change  Initial JS 143.49KiB 143.49KiB
No change  Initial CSS 31.84KiB 31.84KiB
No change  Cache Invalidation 0% 0%
No change  Chunks 7 7
No change  Assets 7 7
No change  Modules 212 212
No change  Duplicate Modules 17 17
No change  Duplicate Code 3.89% 3.89%
No change  Packages 4 4
No change  Duplicate Packages 0 0
Bundle size by type  no changes
                 Current
#4539
     Baseline
#4527
No change  JS 234.68KiB 234.68KiB
No change  Other 100.16KiB 100.16KiB
No change  CSS 31.84KiB 31.84KiB

Bundle analysis reportBranch babu-ch:rs_configProject dashboard


Generated by RelativeCIDocumentationReport issue

@relativeci
Copy link

relativeci bot commented Aug 25, 2025

React Example

#4546 Bundle Size — 237.06KiB (0%).

71675e3(current) vs 1cbccc1 main#4534(baseline)

Bundle metrics  no changes
                 Current
#4546
     Baseline
#4534
No change  Initial JS 0B 0B
No change  Initial CSS 0B 0B
No change  Cache Invalidation 0% 0%
No change  Chunks 0 0
No change  Assets 4 4
No change  Modules 158 158
No change  Duplicate Modules 64 64
No change  Duplicate Code 45.83% 45.83%
No change  Packages 2 2
No change  Duplicate Packages 0 0
Bundle size by type  no changes
                 Current
#4546
     Baseline
#4534
No change  IMG 145.76KiB 145.76KiB
No change  Other 91.3KiB 91.3KiB

Bundle analysis reportBranch babu-ch:rs_configProject dashboard


Generated by RelativeCIDocumentationReport issue

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

🧹 Nitpick comments (4)
packages/rspeedy/core/test/config/fixtures/custom/promise.ts (2)

1-5: Prefer Promise.resolve for immediacy and readability.

This fixture can be simplified without changing semantics. Using the Promise constructor for immediate resolution is unnecessary and slightly noisier.

-export default new Promise(p =>
-  p({
-    source: { entry: 'default' },
-  })
-)
+export default Promise.resolve({
+  source: { entry: 'default' },
+})

1-5: Add a rejected-promise fixture and corresponding test

To cover error paths when a config default export is a rejected promise:

• Create a new fixture at
packages/rspeedy/core/test/config/fixtures/custom/rejected-promise.ts

export default Promise.reject(new Error('boom'))

• In packages/rspeedy/core/test/config/loadConfig.test.ts, immediately after the existing “load promise config” and “load function-promise config” tests, add:

test('load rejected promise config', async () => {
  const cwd = join(__dirname, 'fixtures', 'custom')
  const actual = loadConfig({ cwd, configPath: './rejected-promise.ts' })
  await expect(actual).rejects.toThrow('boom')
})

This will verify that loadConfig correctly surfaces errors when a promise-based config rejects.

packages/rspeedy/core/test/config/fixtures/custom/function-promise.ts (1)

1-6: Use an async function or Promise.resolve to simplify promise-returning config.

Same behavior with less boilerplate; also avoids the Promise constructor anti-pattern.

-export default () =>
-  new Promise(p =>
-    p({
-      source: { entry: 'default' },
-    })
-  )
+export default async () => ({
+  source: { entry: 'default' },
+})

Alternative:

-export default () =>
-  new Promise(p =>
-    p({
-      source: { entry: 'default' },
-    })
-  )
+export default () =>
+  Promise.resolve({
+    source: { entry: 'default' },
+  })
packages/rspeedy/core/test/config/fixtures/custom/function.ts (1)

1-3: Optional: add lightweight type signal to catch shape drift at compile time.

If you have a public Config or ConfigExport type, consider enforcing it here (e.g., with satisfies) so tests fail fast on contract changes. If not, ignore.

Example (adjust import to the actual type path if available):

// import type { Config } from '...'
export default () =>
  ({
    source: { entry: 'default' },
  } /* satisfies Config */)
📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

💡 Knowledge Base configuration:

  • MCP integration is disabled by default for public repositories
  • Jira integration is disabled by default for public repositories
  • Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

📥 Commits

Reviewing files that changed from the base of the PR and between 1644c88 and a79398d.

📒 Files selected for processing (4)
  • .changeset/small-rivers-arrive.md (1 hunks)
  • packages/rspeedy/core/test/config/fixtures/custom/function-promise.ts (1 hunks)
  • packages/rspeedy/core/test/config/fixtures/custom/function.ts (1 hunks)
  • packages/rspeedy/core/test/config/fixtures/custom/promise.ts (1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
  • .changeset/small-rivers-arrive.md
🔇 Additional comments (1)
packages/rspeedy/core/test/config/fixtures/custom/function.ts (1)

1-3: LGTM — minimal, clear fixture.

This cleanly exercises the () => Config branch.

@codspeed-hq
Copy link

codspeed-hq bot commented Aug 25, 2025

CodSpeed Performance Report

Merging #1590 will not alter performance

Comparing babu-ch:rs_config (71675e3) with main (1cbccc1)

Summary

✅ 10 untouched benchmarks

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

🧹 Nitpick comments (4)
packages/rspeedy/core/test/config/defineConfig.test-d.ts (4)

10-11: Tighten helper function types to strengthen the tests

Annotating the helpers makes intent explicit and avoids relying on inference plus casts. This keeps the overload resolution checks crisp.

-const configFn = () => ({} as Config)
-const configAsyncFn = async () => ({} as Config)
+const configFn: () => Config = () => ({} as Config)
+const configAsyncFn: () => Promise<Config> = async () => ({} as Config)

Alternatively (if TS >= 4.9), you can use satisfies for the returned object if you have a minimal literal you want to validate structurally.


29-31: Add a negative test to lock the “no-arg function” restriction

Since the design explicitly does not accept an env parameter, add a compile-time assertion to ensure accidental broadening doesn’t creep in later.

Append near the bottom of this file:

// @ts-expect-error — functions with parameters are not supported by design
defineConfig((env: unknown) => ({} as Config))

33-36: LGTM on the async function variant; consider PromiseLike support (optional)

The async function case is covered well. If you want to be more permissive without affecting runtime, consider accepting PromiseLike<Config> in ConfigExport (and loader) and add a matching type test. Optional, depending on your compatibility goals.


6-7: Add a public re-export of ConfigExport and update the test import

I ran a search and didn’t find any export { ConfigExport } in the package’s public entry (packages/rspeedy/core/src/index.ts), so tests are still coupled to an internal file. To decouple and mirror how you import defineConfig, please:

  • In packages/rspeedy/core/src/index.ts, re-export the type:

     // packages/rspeedy/core/src/index.ts
     // …existing exports…
    +export type { ConfigExport } from './config/defineConfig.js'
  • In the test, import from the barrel instead of the internal path:

     // packages/rspeedy/core/test/config/defineConfig.test-d.ts
    -import type { ConfigExport } from '../../src/config/defineConfig.js'
    +import type { ConfigExport } from '../../src/index.js'

This makes the test resilient to internal file moves and keeps it aligned with your public API.

📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

💡 Knowledge Base configuration:

  • MCP integration is disabled by default for public repositories
  • Jira integration is disabled by default for public repositories
  • Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

📥 Commits

Reviewing files that changed from the base of the PR and between a79398d and ee54795.

📒 Files selected for processing (1)
  • packages/rspeedy/core/test/config/defineConfig.test-d.ts (1 hunks)
🧰 Additional context used
🧬 Code graph analysis (1)
packages/rspeedy/core/test/config/defineConfig.test-d.ts (1)
packages/rspeedy/core/src/config/defineConfig.ts (1)
  • ConfigExport (27-31)
🔇 Additional comments (3)
packages/rspeedy/core/test/config/defineConfig.test-d.ts (3)

19-23: LGTM on the object variant

This asserts that a plain Config object flows through with a Config return type, as intended.


24-27: LGTM on the Promise variant

Correctly preserves Promise<Config> at the call site rather than widening to ConfigExport.


15-17: Confirm all four defineConfig overloads are present

I see three overloads clearly defined in packages/rspeedy/core/src/config/defineConfig.ts—for:

  • config: ConfigConfig
  • config: Promise<Config>Promise<Config>
  • config: () => Config() => Config

However, my regex didn’t catch the overload for a function returning a promise:

defineConfig(config: () => Promise<Config>): () => Promise<Config>

Please verify that this fourth overload exists (it may be split across multiple lines) so that call-site typings remain precise.

• File: packages/rspeedy/core/src/config/defineConfig.ts
• Expected overloads:

  • export function defineConfig(config: Config): Config
  • export function defineConfig(config: Promise): Promise
  • export function defineConfig(config: () => Config): () => Config
  • export function defineConfig(config: () => Promise): () => Promise

@babu-ch babu-ch requested a review from colinaaa August 25, 2025 07:59
colinaaa
colinaaa previously approved these changes Aug 25, 2025
Copy link
Collaborator

@colinaaa colinaaa left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you!

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

🧹 Nitpick comments (2)
packages/rspeedy/core/etc/rspeedy.api.md (2)

141-149: If ConfigExport was introduced, it is not publicly visible here

The AI summary mentions a new ConfigExport type alias. This API report does not expose such a type, suggesting it’s internal-only. If external consumers or d.ts tests rely on ConfigExport, it should be exported; otherwise, keep it internal and update tests to avoid importing it.


141-149: Docstrings for new overloads

Consider brief JSDoc on each overload clarifying when to use each form (sync object, lazy function, async/promise), and that loadConfig will resolve/invoke as needed. This prevents confusion for users migrating configs.

📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

💡 Knowledge Base configuration:

  • MCP integration is disabled by default for public repositories
  • Jira integration is disabled by default for public repositories
  • Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

📥 Commits

Reviewing files that changed from the base of the PR and between ee54795 and 71675e3.

📒 Files selected for processing (2)
  • packages/rspeedy/core/etc/rspeedy.api.md (1 hunks)
  • packages/rspeedy/core/src/config/defineConfig.ts (2 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
  • packages/rspeedy/core/src/config/defineConfig.ts
🧰 Additional context used
📓 Path-based instructions (1)
packages/**/etc/*.api.md

📄 CodeRabbit inference engine (.github/copilot-instructions.md)

packages/**/etc/*.api.md: After running API extractor, commit updated API report files
Check etc/*.api.md files when API changes are needed

Files:

  • packages/rspeedy/core/etc/rspeedy.api.md
🔇 Additional comments (1)
packages/rspeedy/core/etc/rspeedy.api.md (1)

141-149: Overload return types don’t match Issue #1517’s stated signatures—please confirm intended contract

The added overloads return the same shape as the input (function/promise), whereas Issue #1517 lists all overloads returning Config. If the goal is to mirror Vite-style defineConfig and preserve lazy/async exports at the type level, your current signatures are correct, but the issue/PR objectives need updating. If the goal is to make defineConfig always “materialize” to Config at the type level, the overloads should be:

-export function defineConfig(config: () => Config): () => Config;
-export function defineConfig(config: Promise<Config>): Promise<Config>;
-export function defineConfig(config: () => Promise<Config>): () => Promise<Config>;
+export function defineConfig(config: () => Config): Config;
+export function defineConfig(config: Promise<Config>): Config;
+export function defineConfig(config: () => Promise<Config>): Config;

Be aware: forcing Config as the return type while callers export a function/promise would create a type/runtime mismatch for export default defineConfig(() => ({...})). Please confirm the intended API contract and align the issue description or the overloads accordingly.

@colinaaa colinaaa merged commit bc7f532 into lynx-family:main Aug 26, 2025
84 of 98 checks passed
colinaaa pushed a commit that referenced this pull request Aug 26, 2025
This PR was opened by the [Changesets
release](https://github.com/changesets/action) GitHub action. When
you're ready to do a release, you can merge this and the packages will
be published to npm automatically. If you're not ready to do a release
yet, that's fine, whenever you add more changesets to main, this PR will
be updated.


# Releases
## @lynx-js/[email protected]

### Patch Changes

- fix `withInitDataInState` got wrong state in 2nd or more times
`defaultDataProcessor`, now it will keep its own state.
([#1478](#1478))

- change `__CreateElement('raw-text')` to `__CreateRawText('')` to avoid
`setNativeProps` not working
([#1570](#1570))

- Fix wrong render result when using expression as `key`.
([#1541](#1541))

See
[#1371](#1371)
for more details.

- fix: `Cannot read properties of undefined` error when using `Suspense`
([#1569](#1569))

- Add `animate` API in Main Thread Script(MTS), so you can now control a
CSS animation imperatively
([#1534](#1534))

    ```ts
    import type { MainThread } from "@lynx-js/types";

    function startAnimation(ele: MainThread.Element) {
      "main thread";
      const animation = ele.animate([{ opacity: 0 }, { opacity: 1 }], {
        duration: 3000,
      });

      // Can also be paused
      // animation.pause()
    }
    ```

## @lynx-js/[email protected]

### Patch Changes

- Support caching Lynx native events when chunk splitting is enabled.
([#1370](#1370))

When `performance.chunkSplit.strategy` is not `all-in-one`, Lynx native
events are cached until the BTS chunk is fully loaded and are replayed
when that chunk is ready. The `firstScreenSyncTiming` flag will no
longer change to `jsReady` anymore.

- Support exporting `Promise` and function in `lynx.config.ts`.
([#1590](#1590))

- Fix missing `publicPath` using when `rspeedy dev --mode production`.
([#1310](#1310))

- Updated dependencies
\[[`aaca8f9`](aaca8f9)]:
    -   @lynx-js/[email protected]
    -   @lynx-js/[email protected]

## [email protected]

### Patch Changes

- Add `@lynx-js/preact-devtools` by default.
([#1593](#1593))

## @lynx-js/[email protected]

### Patch Changes

- Bump @clack/prompts to v1.0.0-alpha.4
([#1559](#1559))

## @lynx-js/[email protected]

### Patch Changes

- Support using multiple times in different environments.
([#1498](#1498))

- Support caching Lynx native events when chunk splitting is enabled.
([#1370](#1370))

When `performance.chunkSplit.strategy` is not `all-in-one`, Lynx native
events are cached until the BTS chunk is fully loaded and are replayed
when that chunk is ready. The `firstScreenSyncTiming` flag will no
longer change to `jsReady` anymore.

- Updated dependencies
\[[`f0d483c`](f0d483c),
[`e4d116b`](e4d116b),
[`d33c1d2`](d33c1d2)]:
    -   @lynx-js/[email protected]
    -   @lynx-js/[email protected]
    -   @lynx-js/[email protected]
    -   @lynx-js/[email protected]
    -   @lynx-js/[email protected]
    -   @lynx-js/[email protected]
    -   @lynx-js/[email protected]

## @lynx-js/[email protected]

### Patch Changes

- Support using multiple times in different environments.
([#1498](#1498))

- Alias `@lynx-js/preact-devtools` to `false` to reduce an import of
empty webpack module.
([#1593](#1593))

## @lynx-js/[email protected]

### Patch Changes

- Support `lynx.createSelectorQuery().select()` and `setNativeProps` API
([#1570](#1570))

## @lynx-js/[email protected]

### Patch Changes

- fix: globalThis is never accessible in MTS
([#1531](#1531))

-   Updated dependencies \[]:
    -   @lynx-js/[email protected]

## @lynx-js/[email protected]

### Patch Changes

- fix: fake uidisappear event
([#1539](#1539))

- Updated dependencies
\[[`70863fb`](70863fb)]:
    -   @lynx-js/[email protected]
    -   @lynx-js/[email protected]
    -   @lynx-js/[email protected]
    -   @lynx-js/[email protected]

## @lynx-js/[email protected]

### Patch Changes

- fix: globalThis is never accessible in MTS
([#1531](#1531))

- Updated dependencies
\[[`70863fb`](70863fb)]:
    -   @lynx-js/[email protected]
    -   @lynx-js/[email protected]

## @lynx-js/[email protected]

### Patch Changes

- fix: globalThis is never accessible in MTS
([#1531](#1531))

- Updated dependencies
\[[`70863fb`](70863fb)]:
    -   @lynx-js/[email protected]
    -   @lynx-js/[email protected]
    -   @lynx-js/[email protected]

## @lynx-js/[email protected]

### Patch Changes

- Add new `LynxCacheEventsPlugin`, which will cache Lynx native events
until the BTS chunk is fully loaded, and replay them when the BTS chunk
is ready. ([#1370](#1370))

- Updated dependencies
\[[`aaca8f9`](aaca8f9)]:
    -   @lynx-js/[email protected]

## @lynx-js/[email protected]

### Patch Changes

- Updated dependencies
\[[`aaca8f9`](aaca8f9)]:
    -   @lynx-js/[email protected]

## @lynx-js/[email protected]

### Patch Changes

- Updated dependencies
\[[`aaca8f9`](aaca8f9)]:
    -   @lynx-js/[email protected]

## @lynx-js/[email protected]

### Patch Changes

- Updated dependencies
\[[`aaca8f9`](aaca8f9)]:
    -   @lynx-js/[email protected]

## @lynx-js/[email protected]

### Patch Changes

- Always inline the background script that contains rspack runtime
module. ([#1582](#1582))

- Updated dependencies
\[[`aaca8f9`](aaca8f9)]:
    -   @lynx-js/[email protected]

## @lynx-js/[email protected]

### Patch Changes

- Add `lynxCacheEventsSetupList` and `lynxCacheEvents` to
RuntimeGlobals. It will be used to cache Lynx native events until the
BTS chunk is fully loaded, and replay them when the BTS chunk is ready.
([#1370](#1370))

## [email protected]



## @lynx-js/[email protected]



## @lynx-js/[email protected]



## @lynx-js/[email protected]

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
@babu-ch babu-ch deleted the rs_config branch August 26, 2025 08:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Feature]: Support Promise and function in defineConfig

2 participants