Customize and extend Amplication’s code generation process using Before and After lifecycle functions in plugins.
before
and after
hooks:
before
: This function executes before Amplication emits the main event logic. Use it to modify event parameters and tailor the default behavior before it happens.after
: This function executes after Amplication’s core event logic. It provides access to the generated modules or files, allowing you to apply transformations, add custom logic, or restructure outputs.EventParams
interface (T extends EventParams
), providing you with type-safe access to the relevant data for that particular stage of the generation process.
before
and after
functions to understand how you can interact with Amplication’s code generation:
T
is
defined by the specific event interface, giving you access to relevant data
points to influence the generation.FileMap
is used in blueprint plugins to represent generated files. It
provides a way to access and modify the generated files before they are
written to disk.before
function should return a Promise
that resolves to the
(potentially modified) eventParams
. Returning the modified eventParams
allows you to influence the subsequent default behavior of the event.after
function should return a Promise
resolving to the (potentially modified) ModuleMap
. Returning the modified ModuleMap
ensures your changes are incorporated into the final generated output.before
and after
lifecycle functions have access to a global context
object that provides essential data and utilities. This context is shared between events and contains crucial information about your application.
Here are the key properties available in the context object:
Name | Type | Description |
---|---|---|
resourceType | keyOf typeOf EnumResourceType | The type of resource: MessageBroker , ProjectConfiguration , Service |
resourceInfo | AppInfo | General application data including name, description, version, ID, URL, and settings |
entities | Entity[] | List of entities in the service |
roles | Roles | List of roles in the service |
pluginInstallations | PluginInstallations | List of installed plugins |
topics | Topic[] | List of topics connected to the service |
modules | ModuleMap | Map of generated modules (files) |
DTOs | DTOs | List of generated DTOs |
plugins | PluginMap | Map of event names with their before/after functions and event parameters |
logger | BuildLogger | Logger for creating user-facing build logs |
utils | ContextUtil | Utility functions including skipDefaultBehavior and importStaticModules |
clientDirectories | ClientDirectories | Paths for admin UI generation (base, src, auth, public, api directories) |
serverDirectories | ServerDirectories | Paths for server generation (base, src, auth, scripts, messageBroker directories) |
before
function provides a powerful capability to skip Amplication’s default behavior through the context object. This allows you to completely override the default functionality with your own implementation:
skipDefaultBehavior
is set to false
. When set to true
, Amplication will skip its default implementation, and you must provide alternative logic either in the before
function or in the corresponding after
function.
skipDefaultBehavior
with caution. Skipping default behavior without
providing proper alternative functionality can lead to unexpected results,
especially if other generated files depend on the skipped output.after
Functionsafter
functions is to restructure the generated files. Imagine you need to enforce a specific folder structure for all your organization’s services. The after
function is the perfect place to achieve this.
For example, you might want to:
resolvers
directory.after
function gives you the flexibility to manipulate the generated ModuleMap
or FileMap
and reorganize files as needed to meet your project’s architectural requirements.
before
and after
functions is to see them in action.
We encourage you to dive into the code of Amplication’s official plugins. These plugins are built using the same plugin framework and provide numerous practical examples of how to implement before
and after
lifecycle functions for various customization tasks.
By exploring these examples, you can gain insights into:
before
and after
functions:
Targeted Modifications in `after` Functions
after
functions, focus on making specific, targeted changes to the generated files. Avoid wholesale replacement of entire files unless absolutely necessary. Smaller, incremental modifications are easier to understand, maintain, and less likely to introduce unintended side effects.Careful Template Adjustments in `before` Functions
before
functions, exercise caution. Changes
to templates can have a broad impact on code generation. Ensure you thoroughly
test any template modifications to prevent unintended consequences or
breakages in the generated code.Strategic Use of `skipDefaultBehavior`
skipDefaultBehavior
option (available in some events) should be used
judiciously within before
functions. Only utilize it if you intend to
completely override Amplication’s default code generation for that
specific event. In most cases, you’ll want to extend or modify the default
behavior, not replace it entirely.