We are reviving the RFC process for major changes to the design of frontend components, with the goal—going forward—of clearly documenting these changes and decisions as we’re making them.
RFCs are an opportunity for community involvement and comment. As a process note, RFCs can only be approved with approvals from at least two reviewers, ideally representing two separate implementations / stakeholders.
We welcome any comments you have, including comments on the RFC process itself (though, ideally, please report those in this thread or on Slack and not as part of the comments on any particular RFC).
Thanks for reviving the RFC process. The static config schemas proposal looks solid — extracting schemas as JSON at build time so modules don’t need to load just to resolve their configuration is a clear win for boot performance and tooling.
Looking at the modules like (esm-patient-registration-app, esm-service-queues-app), we have several cross-field validators with computed error messages — e.g., validating that section definitions reference valid field IDs, or that column types match their config. The approach of keeping these as functions in config-validators.ts while everything else ships as JSON works well for us, and the expanded built-in vocabulary (greaterThan, positiveInteger, etc.) should cover most of the simpler cases.
One question: during the transition window where defineConfigSchema still works, will modules with existing custom validators need any changes, or will the build extraction handle those automatically until we migrate to config-validators.ts?
will modules with existing custom validators need any changes, or will the build extraction handle those automatically until we migrate to config-validators.ts?
I think we’ll attempt to make a best-effort to make this apply without any changes. config-validators.ts is there as a “common practice, not enforced”, meaning it’s not meant to be something required, just a “best practice” for organizing code.
That said, any concrete implementation would be dependent on Webpack / RSpack’s tree-walking and tree-shaking to identify functions and extract them, which means there could be limits to what we can reasonably extract.