Open-source serverless enterprise CMS. Includes a headless CMS, page builder, form builder, and file manager. Easy to customize and expand. Deploys to AWS.
For quite some time, we've had multiple approaches when it comes to locating custom code (plugins/extensions), where sometimes we'd be creating code inside of the apps/{project-application} folder , and sometimes outside of it, within a new yarn workspace, .e.g. packages/myPackage. Our docs contain examples with both approaches being used.
And not only that. Once a piece of code was written, users would still manually have to import it in an entrypoint file, like:
GraphQL API - apps/api/graphql/src/index.ts (a ~150 LOC file 🫢)
Admin - apps/admin/src/App.tsx
So, all in all, not only there wasn't a one-and-only approach of doing things / locating the code, but also, having to perform multiple steps in order to bring a plugin/extension to life was simply not ideal DX and error-prone.
With this PR, we are fixing this, by basically introducing the extensions folder in project root, and making it the central place where users will be creating their plugins/extensions. So, this way, users won't have to deal much (if at all) with the apps folder.
[!NOTE]
Keeping users outside of the apps folder also helps with improving project upgrades (more stability).
Furthermore, users won't even have to register their plugins in mentioned entrypoint files, because, via the new New Extension scaffold that we're also introducing, this daunting step is automatically done for them.
One other improvement we did here was moving the apps/theme folder into extensions/theme, so that, again, users have less reasons to go into the apps folder. Which also finally makes the apps folder only contain the actual project applications, which makes 100% sense:
2. Introducing the @webiny/api-serverless-cms Package
With this PR, we've also introduced the @webiny/api-serverless-cms package, which exports the plugin factories users often need while developing on the backend.
The main factories are createContextPlugin and createGraphQLSchemaPlugin, which will be now promoted as the standard way of extending on the backend. The main reason is that these factories automatically have the whole context object defined, so user's don't need to do anything in order to have the full auto complete and type-safety.
Changes
For quite some time, we've had multiple approaches when it comes to locating custom code (plugins/extensions), where sometimes we'd be creating code inside of the
apps/{project-application}
folder , and sometimes outside of it, within a new yarn workspace, .e.g.packages/myPackage
. Our docs contain examples with both approaches being used.And not only that. Once a piece of code was written, users would still manually have to import it in an entrypoint file, like:
apps/api/graphql/src/index.ts
(a ~150 LOC file 🫢)apps/admin/src/App.tsx
So, all in all, not only there wasn't a one-and-only approach of doing things / locating the code, but also, having to perform multiple steps in order to bring a plugin/extension to life was simply not ideal DX and error-prone.
With this PR, we are fixing this, by basically introducing the
extensions
folder in project root, and making it the central place where users will be creating their plugins/extensions. So, this way, users won't have to deal much (if at all) with theapps
folder.Furthermore, users won't even have to register their plugins in mentioned entrypoint files, because, via the new
New Extension
scaffold that we're also introducing, this daunting step is automatically done for them.https://github.com/webiny/webiny-js/assets/5121148/260aa124-a26e-49c8-b5f7-f74bcede4aa2
Other Changes
1.
apps/theme
->extensions/theme
One other improvement we did here was moving the
apps/theme
folder intoextensions/theme
, so that, again, users have less reasons to go into theapps
folder. Which also finally makes theapps
folder only contain the actual project applications, which makes 100% sense:2. Introducing the
@webiny/api-serverless-cms
PackageWith this PR, we've also introduced the
@webiny/api-serverless-cms
package, which exports the plugin factories users often need while developing on the backend.The main factories are
createContextPlugin
andcreateGraphQLSchemaPlugin
, which will be now promoted as the standard way of extending on the backend. The main reason is that these factories automatically have the wholecontext
object defined, so user's don't need to do anything in order to have the full auto complete and type-safety.How Has This Been Tested?
Manually.
Documentation
Changelog. Docs. Videos.