fix: init admin typings and scaffold regressions#107
fix: init admin typings and scaffold regressions#107innerdvations merged 8 commits intostrapi:mainfrom
Conversation
Signed-off-by: Andrew Bone <AndrewB05@gmail.com>
addMenuLink['Component'] expects
```tsx
() => Promise<{
default: React.ComponentType;
}>;
```
Meaning the component must be the default export
Signed-off-by: Andrew Bone <AndrewB05@gmail.com>
🦋 Changeset detectedLatest commit: ebcae7a The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
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 |
|
Documentation Updates 1 document(s) were updated by changes in this PR: admin-permissions-for-pluginsView Changes@@ -152,11 +152,7 @@
id: `${PLUGIN_ID}.plugin.name`,
defaultMessage: PLUGIN_ID,
},
- Component: async () => {
- const { App } = await import('./pages/App');
-
- return App;
- },
+ Component: () => import('./pages/App'),
permissions: [
pluginPermissions.accessOverview[0],
], |
- Use the `StrapiAppPlugin` type rather than remaking it - fix registerTrads so it actually transforms languages. Signed-off-by: Andrew Bone <AndrewB05@gmail.com>
|
|
Thanks for this! I pushed a change that:
If this looks good to you still, I’m happy to merge! |
Register|
The reason I changed the export to default was because the addMenuLink type expects it to be a default export. As it stands now it will throw and type error. addMenuLink: (link: Omit<MenuItem, 'Component'> & {
Component: () => Promise<{
default: React.ComponentType;
}>;
}) => void;We could fake the import in Component: async () => {
const { App } = await import('./pages/App');
return {default: App};
},But other than that everything looks great. |
|
Thanks for this! I think this has highlighted a discrepancy in our docs more than anything else (see PR mentioned above). We seem to be documenting a deprecated import syntax. wdyt @innerdvations ? If we go ahead with those docs changes, I think we can move back to something closer to the first diff you had. Using a diff like the one below. I've marked this as |
|
Yeah, let's just move forward with this improvement. I just reverted my change back to @Link2Twenty 's default export, and we'll consider it a documentation problem. Does that seem right to you too @jhoward1994 ? |
|
Thanks @innerdvations yeah that seems right to me |
|





What does it do?
Remove the
anyfrom register and update the function so it matches the existing type.One of the changes is to make App a default export, this is simply to make the linter happy and changing the type might be the correct way to go.
Why is it needed?
Types are good
How to test it?
Load the types in and see the linter is happy.
Related issue(s)/PR(s)
N/A
Edit:
I noticed there was already a type the describes this whole export so I've set it up to use that instead.
While I was in there I realised the mapping of translation keys wasn't happening so I've added that in.
Let me know if yo need that to be a send PR.