-
Notifications
You must be signed in to change notification settings - Fork 111
feat(rspeedy): Support Promise and function in defineConfig #1590
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
📝 WalkthroughWalkthroughAdds 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
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Assessment against linked issues
Suggested reviewers
Poem
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 unit tests
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. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR/Issue comments)Type Other keywords and placeholders
Status, Documentation and Community
|
🦋 Changeset detectedLatest commit: ee54795 The changes in this PR will be included in the next version bump. This PR includes changesets to release 3 packages
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 |
There was a problem hiding this 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 defineConfigpackages/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
loadConfigthrows 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.
validatenow returnsConfigExport, which is perfect for pre-resolution checks. After we resolve the value inloadConfig, we need aConfig-only validator to avoidas Configcasts 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
loadConfigcan callassertConfigObject(resolved, configPath)instead of reusingvalidate+ 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.
📒 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
validateaccepts 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 AligndefineConfig(Promise<Config>)SemanticsThe current overloads in
packages/rspeedy/core/src/config/defineConfig.ts(lines 32–37) treat aPromise<Config>input as an identity, returningPromise<Config>—not unwrapping it toConfigas the examples in Issue #1517 imply. Since you can’t synchronously resolve a promise, resolution must occur later inloadConfig.Please ensure that:
- The documentation/examples in Issue #1517 (and any JSDoc) are updated to show
and include a note that promise inputs are not unwrapped bydefineConfig(Promise<Config>): Promise<Config>defineConfigitself.- A short JSDoc comment is added above
defineConfigclarifying it passes through Promise inputs directly.- The
loadConfigimplementation (inpackages/rspeedy/core/src/config/loadConfig.ts) correctly awaits or invokes the exportedconfig—i.e., that promise inputs are resolved at load time.
colinaaa
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you!
Co-authored-by: Qingyu Wang <[email protected]> Signed-off-by: bab <[email protected]>
Co-authored-by: Qingyu Wang <[email protected]> Signed-off-by: bab <[email protected]>
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
Web Explorer#4539 Bundle Size — 366.68KiB (0%).71675e3(current) vs 1cbccc1 main#4527(baseline) Bundle metrics
|
| Current #4539 |
Baseline #4527 |
|
|---|---|---|
143.49KiB |
143.49KiB |
|
31.84KiB |
31.84KiB |
|
0% |
0% |
|
7 |
7 |
|
7 |
7 |
|
212 |
212 |
|
17 |
17 |
|
3.89% |
3.89% |
|
4 |
4 |
|
0 |
0 |
Bundle size by type no changes
| Current #4539 |
Baseline #4527 |
|
|---|---|---|
234.68KiB |
234.68KiB |
|
100.16KiB |
100.16KiB |
|
31.84KiB |
31.84KiB |
Bundle analysis report Branch babu-ch:rs_config Project dashboard
Generated by RelativeCI Documentation Report issue
React Example#4546 Bundle Size — 237.06KiB (0%).71675e3(current) vs 1cbccc1 main#4534(baseline) Bundle metrics
|
| Current #4546 |
Baseline #4534 |
|
|---|---|---|
0B |
0B |
|
0B |
0B |
|
0% |
0% |
|
0 |
0 |
|
4 |
4 |
|
158 |
158 |
|
64 |
64 |
|
45.83% |
45.83% |
|
2 |
2 |
|
0 |
0 |
Bundle size by type no changes
| Current #4546 |
Baseline #4534 |
|
|---|---|---|
145.76KiB |
145.76KiB |
|
91.3KiB |
91.3KiB |
Bundle analysis report Branch babu-ch:rs_config Project dashboard
Generated by RelativeCI Documentation Report issue
There was a problem hiding this 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 testTo 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.tsexport 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
loadConfigcorrectly 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.
📒 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 Performance ReportMerging #1590 will not alter performanceComparing Summary
|
There was a problem hiding this 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 testsAnnotating 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” restrictionSince 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>inConfigExport(and loader) and add a matching type test. Optional, depending on your compatibility goals.
6-7: Add a public re-export ofConfigExportand update the test importI 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 importdefineConfig, 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.
📒 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 variantThis asserts that a plain
Configobject flows through with aConfigreturn type, as intended.
24-27: LGTM on the Promise variantCorrectly preserves
Promise<Config>at the call site rather than widening toConfigExport.
15-17: Confirm all fourdefineConfigoverloads are presentI see three overloads clearly defined in
packages/rspeedy/core/src/config/defineConfig.ts—for:
config: Config→Configconfig: Promise<Config>→Promise<Config>config: () => Config→() => ConfigHowever, 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
colinaaa
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you!
There was a problem hiding this 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: IfConfigExportwas introduced, it is not publicly visible hereThe AI summary mentions a new
ConfigExporttype alias. This API report does not expose such a type, suggesting it’s internal-only. If external consumers or d.ts tests rely onConfigExport, it should be exported; otherwise, keep it internal and update tests to avoid importing it.
141-149: Docstrings for new overloadsConsider brief JSDoc on each overload clarifying when to use each form (sync object, lazy function, async/promise), and that
loadConfigwill 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.
📒 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
Checketc/*.api.mdfiles 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 contractThe 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-styledefineConfigand 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 makedefineConfigalways “materialize” toConfigat 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
Configas the return type while callers export a function/promise would create a type/runtime mismatch forexport default defineConfig(() => ({...})). Please confirm the intended API contract and align the issue description or the overloads accordingly.
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>
close #1517
Summary by CodeRabbit
New Features
Tests
Chores
Checklist