InMemoryFormPersistenceService is JS-only, so no JVM unit spec can use it #50

New issue

Open

opened 2026-09-07 08:54:36 +00:00 by mph · 0 comments

mph commented

2026-09-07 08:54:36 +00:00

Owner

What

InMemoryFormPersistenceService lives in the js source set only:

forms/js/src/main/scala/works/iterative/forms/service/impl/InMemoryFormPersistenceService.scala

So the published iw-support-forms_3 (JVM) jar carries no impl/InMemory* class at all, while iw-support-forms_sjs1_3 does. Verified by unzip -l on both jars at version 0.1.23 from a consuming project, and by fd over this repo's own tree.

Why it is a problem

A JVM unit spec that needs a FormPersistenceService collaborator cannot construct one, even though the service is a pure in-memory stand-in with no platform-specific behaviour. Every JVM consumer has to hand-roll the same stub.

Two such stubs already exist in one downstream project (medeca-modul-poptavky) — CaseSummaryServiceSpec.scala and PodejOpravuDokumentaceValidationSpec.scala:43-51 — each a get/put pair over a fixed value, written only because the shared implementation is unreachable from the JVM.

The absence is also silent in the worst way: the class is visible in the API docs and in the sources, so the natural first move is to import it, and the failure arrives as an unresolved name with no hint that a platform is the reason.

Why it looks like an oversight rather than a decision

The implementation has nothing JS-specific in it — it is a Ref[Map[FormIdent, SavedForm]] and two ZIO methods:

class InMemoryFormPersistenceService(data: Ref[Map[FormIdent, SavedForm]])
    extends FormPersistenceService:
    override def put(id: FormIdent)(formData: Option[SavedForm]): UIO[Unit] = ...
    override def get(id: FormIdent): UIO[Option[SavedForm]] = ...

FormPersistenceService, the trait it implements, is already in forms/shared/src/main/scala/works/iterative/forms/service/, and forms/shared/.../service/impl/ already exists as a directory.

Proposed fix

Move the file from forms/js/src/main/scala/... to forms/shared/src/main/scala/... — same package, same content. It should cross-build unchanged.

If there is a reason it was deliberately kept off the JVM, that reason is worth a comment in the file, because the current arrangement reads as an accident.

## What `InMemoryFormPersistenceService` lives in the **js** source set only: ``` forms/js/src/main/scala/works/iterative/forms/service/impl/InMemoryFormPersistenceService.scala ``` So the published `iw-support-forms_3` (JVM) jar carries no `impl/InMemory*` class at all, while `iw-support-forms_sjs1_3` does. Verified by `unzip -l` on both jars at version `0.1.23` from a consuming project, and by `fd` over this repo's own tree. ## Why it is a problem A JVM unit spec that needs a `FormPersistenceService` collaborator cannot construct one, even though the service is a pure in-memory stand-in with no platform-specific behaviour. Every JVM consumer has to hand-roll the same stub. Two such stubs already exist in one downstream project (medeca-modul-poptavky) — `CaseSummaryServiceSpec.scala` and `PodejOpravuDokumentaceValidationSpec.scala:43-51` — each a `get`/`put` pair over a fixed value, written only because the shared implementation is unreachable from the JVM. The absence is also silent in the worst way: the class is visible in the API docs and in the sources, so the natural first move is to import it, and the failure arrives as an unresolved name with no hint that a platform is the reason. ## Why it looks like an oversight rather than a decision The implementation has nothing JS-specific in it — it is a `Ref[Map[FormIdent, SavedForm]]` and two ZIO methods: ```scala class InMemoryFormPersistenceService(data: Ref[Map[FormIdent, SavedForm]]) extends FormPersistenceService: override def put(id: FormIdent)(formData: Option[SavedForm]): UIO[Unit] = ... override def get(id: FormIdent): UIO[Option[SavedForm]] = ... ``` `FormPersistenceService`, the trait it implements, is already in `forms/shared/src/main/scala/works/iterative/forms/service/`, and `forms/shared/.../service/impl/` already exists as a directory. ## Proposed fix Move the file from `forms/js/src/main/scala/...` to `forms/shared/src/main/scala/...` — same package, same content. It should cross-build unchanged. If there is a reason it was deliberately kept off the JVM, that reason is worth a comment in the file, because the current arrangement reads as an accident.