- Home
- Skills
- Psincraian
- Myfy
- Module Development
module-development_skill
- Python
83
GitHub Stars
1
Bundled Files
2 months ago
Catalog Refreshed
4 months ago
First Indexed
Readme & install
Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.
Installation
Preview and clipboard use veilstrat where the catalogue uses aiagentskills.
npx veilstrat add skill psincraian/myfy --skill module-development- SKILL.md7.1 KB
Overview
This skill documents the myfy module development protocol, lifecycle phases, and extension patterns. It explains how to create modules, register settings and providers, declare dependencies, and use built-in module types like WebModule, DataModule, FrontendModule, TasksModule, UserModule, CliModule, AuthModule, and RateLimitModule. It focuses on practical patterns for configure/extend/finalize methods and safe runtime startup/shutdown.
How this skill works
Modules implement a BaseModule and follow a phased lifecycle: discovery, dependency validation, configure, extend, compile, finalize, start, and stop. During configure(), modules register providers and settings in the DI container. extend() can modify other registrations before the container compiles. finalize() is where singletons are safe to resolve and wiring between modules happens. start()/stop() run runtime behavior in dependency order and in reverse respectively.
When to use it
- Creating a new feature or integration that must plug into the app lifecycle
- Registering settings, services, or DI providers for a feature
- Declaring dependencies on core modules like WebModule or DataModule
- Mounting ASGI apps, registering CLI commands, or adding auth/ratelimit hooks
- Extending or customizing other modules before container compilation
Best practices
- Call super().__init__(name) in module constructor
- Accept optional settings in __init__ to support testing and overrides
- Keep configure() pure: only register providers and no side effects
- Check container for existing ProviderKey to avoid double registration
- Use finalize() to resolve and configure singletons after compilation
- Make start() and stop() idempotent and add logging for visibility
Example use cases
- Build a MyFeatureModule that registers MyFeatureSettings and a singleton service
- Declare requires = [WebModule, DataModule] to ensure proper init order when you need routing and DB
- Provide an IWebExtension to mount a sub-ASGI app in finalize()
- Register CLI commands via CliModule providers during configure()
- Use TasksModule to register background job handlers and start them in start()
FAQ
Use extend() to alter other modules' registrations before the DI container compiles. Use finalize() to resolve singletons and perform wiring after the container has been built.
How do I avoid duplicate settings registration?
Check for an existing ProviderKey in the container before registering. Optionally accept settings in __init__ and only call load_settings when not provided.