Feature request: plugin “preprocessor” option #2022
Conversation
Adds support for a “preprocessor” flag in plugin options that causes the plugin to be executed before the core zenstack plugins. This allows for plugins that modify the schema prior zenstack enhancements.
📝 WalkthroughWalkthroughThe changes introduce a new mechanism in the Changes
Sequence Diagram(s)sequenceDiagram
participant PR as PluginRunner
participant PP as Preprocessor Plugins
participant UP as User Plugins
PR->>PR: calculateAllPlugins()
Note over PR: Categorize plugins into \npreprocessorPlugins (PP) and otherPlugins (UP)
PR->>PR: runUserPlugins(PP)
loop For each preprocessor plugin
PR->>PP: Execute plugin logic
end
PR->>PR: runUserPlugins(UP)
loop For each user plugin
PR->>UP: Execute plugin logic
end
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
⏰ Context from checks skipped due to timeout of 90000ms (6)
🔇 Additional comments (5)
✨ Finishing Touches
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
Hey @chunkerchunker , thanks for making this PR! Do you mind sharing a bit more about what kind of modifications you plan to make with the preprocessors? Is it about minipulating the ZModel AST before it's ingested by the core plugins? The AST nodes have internal linkages (mainly named references to their resolved declarations), so handling them can be tricky or may result in downstream errors. |
|
Hi @ymc9, yes that's exactly the usage. Specifically, I have a crdt sync engine that I've built for my app (that has some unique properties not satisfied by existing engines I looked at, like vlcn.io and electric-sql). My plugin looks for models that have been annotated for supporting sync, and it adds corresponding HLC_ and updatedAt_ for each sync'd field, along with a some other boilerplate fields at the model level. Having a plugin do this lets me automate everything and make it maintainable. I did notice when implementing this your point about internal linkages in the AST nodes. So, the way I got things to work in my plugin was to create a single template model in the original schema, and then I copied and modified fields from the template wherever needed (updating the container linkages on the copies). I can understand that you wouldn't want to expose much of your implementation details as API, but do you think there's a small enough surface area of the AST that can be relied on to make this work? Or another option is just to say that any usage is at the user's risk, in a similar way to how Prisma treats the dmmf? Thanks for the consideration! |
|
Thanks for the explanation @chunkerchunker . The ZModel AST is a grey area of ZenStack's "API", since the surface is really wide. It's fairly stable now and usually things are added instead of changed/deleted, however I feel it's difficult to let it follow semver. Yes, it's more like Prisma's DMMF. For your use case, if it's mostly about introducing simple fields I guess the risk is low. Thing involving altering relations or inheritance hierarchy can be more subtle. I think it's fine to introduce the |
Would you be open to this feature (or something similar)? I have a use case where I want to make a large number of modifications to the schema based on some custom attributes, and I want these changes to be made prior to Zenstack's plugins running, so that I still get all of the Zenstack features on top of my modifications. This pull request is a tiny change that recognizes the "preprocessor" flag in a plugin's config, which causes that plugin to run before Zenstack's plugins.
Happy to make any changes, but wanted to run it by you to see if there are better options.
Thanks!