Introducing the extensions Folder and the New Extension Scaffold
#4111
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
adrians5j
commented
May 6, 2024
adrians5j
commented
May 6, 2024
packages/cwp-template-aws/template/common/apps/admin/src/App.tsx
Outdated
Show resolved
Hide resolved
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
adrians5j
changed the title
extensions Folder extensions Folder and the New Extension Scaffold
|
/cypress |
|
Cypress E2E tests have been initiated (for more information, click here). ✨ |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.tsxSo, 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
extensionsfolder 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 theappsfolder.Note
Keeping users outside of the
appsfolder 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 Extensionscaffold that we're also introducing, this daunting step is automatically done for them.exts-scaffoldds.mov
Other Changes
1.
apps/theme->extensions/themeOne other improvement we did here was moving the
apps/themefolder intoextensions/theme, so that, again, users have less reasons to go into theappsfolder. Which also finally makes theappsfolder only contain the actual project applications, which makes 100% sense:2. Introducing the
@webiny/api-serverless-cmsPackageWith this PR, we've also introduced the
@webiny/api-serverless-cmspackage, which exports the plugin factories users often need while developing on the backend.The main factories are
createContextPluginandcreateGraphQLSchemaPlugin, which will be now promoted as the standard way of extending on the backend. The main reason is that these factories automatically have the wholecontextobject 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.