Automate running Node.js tests on every pull request

[nikoscham]

This issue has been proposed by @ferrari212 (https://github.com/orgs/FEAScript/discussions/17).
The goal is to have immediate feedback for contributors when a change breaks an example.

Tasks

• Use existing Node.js examples (https://github.com/FEAScript/FEAScript-core/tree/main/examples) as automated tests
• Integrate with GitHub Actions

[silky-x0]

@nikoscham Are you working on this?

[nikoscham]

@nikoscham Are you working on this?

Hey @silky-x0, thanks for checking in! I haven't started working on this yet. Are you interested in taking it on?

[silky-x0]

@nikoscham but let me first analyse the task, there are multiple things to consider,

Complexity Analysis & Risks

Concern	Difficulty	Mitigation / Notes
Adapting examples to be purely scriptable	Medium	Some examples might assume interactive use, manual inspection, or visualization. Refactor (e.g. parameterize, isolate logic).
Handling non-deterministic output	Medium–High	If examples log timestamps, randomness, or floating rounding errors, use tolerant comparison (fuzzy match, tolerances).
Dependencies, environment setup, data files	Low–Medium	Examples may rely on extra modules, assets, geometry files, etc. Ensure correct environment setup in CI.
Time / resource / performance constraints in CI	Medium	Heavy examples (e.g. PDE solving, mesh generation) may time out. Restrict size or run in a “long test” pipeline.
Maintenance burden	Low–Medium	Adding/changing examples requires updating harness and expected outputs.
Parallelization, caching, flakiness	Medium	Use parallel execution and caching (node_modules). Watch for flaky example runs.

[nikoscham]

Great analysis @silky-x0, thanks for laying this out so clearly! Some considerations:

Adapting examples to be purely scriptable Medium Some examples might assume interactive use, manual inspection, or visualization. Refactor (e.g. parameterize, isolate logic).

I suggest we exclude any visualization or interactive examples for now, and only include those listed here: https://github.com/FEAScript/FEAScript-core/tree/main/examples

Handling non-deterministic output Medium–High If examples log timestamps, randomness, or floating rounding errors, use tolerant comparison (fuzzy match, tolerances).

I don’t think this will be a major issue. In most FEA cases the results should be deterministic, provided the mesh and solution parameters remain constant.

[silky-x0]

@nikoscham Okey Got it, I'll start working on this now! and also please tag this with hacktoberfest and later hacktoberfest-accepted after merge, thanks!

[nikoscham]

Thanks @silky-x0 for your interest in contributing to the FEAScript project!
Please also consider ⭐️ the library!

[nikoscham]

@nikoscham Okey Got it, I'll start working on this now! and also please tag this with hacktoberfest and later hacktoberfest-accepted after merge, thanks!

@silky-x0 Just a heads-up: the generalFormPDEScript example (https://github.com/FEAScript/FEAScript-core/tree/main/examples/generalFormPDEScript) is not yet fully integrated with the rest of FEAScript’s ecosystem, so please don’t include it in the running tests for now.

[silky-x0]

@nikoscham Yesss, will keep in mind.