Add config for running web-forms via containers

[spwoodcock]

I have verified this PR works in these browsers (latest versions):

• Chrome
• Firefox
• Safari (macOS)
• Safari (iOS)
• Not applicable

What else has been done to verify that this works as intended?

• I successfully uploaded a form, attached
• The form is processed by xlsform-online and then viewed in web-forms preview.

Why is this the best possible solution? Were any other approaches considered?

• It's probably not the best possible solution, but it's one option that could make running web-forms easier for devs.

How does this change affect users? Describe intentional changes to behavior and behavior that could have accidentally been affected by code changes. In other words, what are the regression risks?

No change.

Do we need any specific form for testing your changes? If so, please attach one.

See above.

What's changed

• Related to the comment here Consider alternatives to tree-sitter #41 (comment)
• I had trouble setting up web-forms for development due to the tree-sitter library needing WASM compilation.
  • As mentioned in the linked issue, doing this requires either docker or emscripten emsdk.
  • I run almost everything inside containers, meaning docker is not installed unless I used DIND.
  • Installing emsdk would also be ephemeral, unless I decided to add to my dev stack.
• While I admit these issues may be somewhat specific to my config, the linked issue does suggest adding a pathway to build tree-sitter.wasm via docker & this setup does that!

What I included:

• Updating the default ports for the xlsform-online service and web-forms to less standard ports, that are less likely to be in use on a dev machine: 8000 --> 8558 & random port assigned by vite --> 5173 (also used for playwright devserver).
• Adding a Containerfile that builds the packages (including the tree-sitter.wasm file) and installs required dependencies.
• A compose file that runs both xlsform-online and web-forms preview together.
• I added all these files under contrib/containers, suggesting it's not maintained as part of the core library (not officially maintained / guaranteed to work). I'm not sure if everyone is as keen on containers as I am, so thought this most appropriate.

Alternatives:

• Alternatively, only the tree-sitter.wasm compilation could be containerised, output to the local development machine, then yarn used as normal for local development.
• However this approach wouldn't also add xlsform-online, which I think is quite helpful to bundle.

Open to suggestions of alternative approaches, or feel free to close this PR if it's not useful 😄

Update 15-04-2025:

• I also needed to run tests, so added a small config to run tests via the container too.
• The advantage here is that users don't need to install ~5GB of dependencies, including 3 web browsers to playwright.

[changeset-bot]

⚠️ No Changeset found

Latest commit: defd256

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[lognaturel]

Thanks so much for sharing this and I'm sorry we didn't give you feedback before now!

I'm going to close this because we're in the process of significantly reworking how Web Form's code is organized. In particular, we've spun https://github.com/getodk/tree-sitter-xpath out as a separate repo so that building the Web Forms packages on top of it don't require rebuilding the native dependency. We don't expect that package to change much.

We will be moving the rest of the packages into the Central Frontend repo shortly. We'll continue publishing them as we do now but will develop them in the frontend monorepo so that we can more easily have end-to-end testing with Central which is our true integration target. We'll spin the preview out into the website repository.

We'll post more details about all of this on the forum shortly but wanted to give you some context here first.