@bartblast I’m curious on your thoughts of what the return value of re.version should be, considering there is not a single version tied to JavaScript Regex capabilities?

❯ iex
Erlang/OTP 27 [erts-15.2.2] [source] [64-bit] [smp:16:16] [ds:16:16:10] [async-threads:1] [jit]

Interactive Elixir (1.18.2) - press Ctrl+C to exit (type h() ENTER for help)
iex(1)> h :re.version/0

  @spec version() :: binary()

since: OTP 20.0

The return of this function is a string with the PCRE version of the system
that was used in the Erlang/OTP compilation.

                                                                                                        
❯ pcre-config --version
8.45

I simply return an empty bitstring for now, bit this test will always fail.

describe "version/0" do
  test "empty string" do
    assert :re.version() == ""
  end
end

Since JavaScript regexes aren’t compatible with the PCRE standard (which Elixir uses), Hologram will eventually transpile them to maintain compatibility.

For now, please hardcode the JavaScript implementation to return "8.44 2020-02-12". In both your JavaScript tests and Elixir consistency tests, use this regex pattern to verify the result format: ~r/^\d+\.\d+\s+\d{4}-\d{2}-\d{2}$/ (this should work in both Elixir and JS)

This way both test suites validate the version string format rather than an exact value, which keeps things consistent.

Eventually, :re.version/0 will fetch the PCRE version from the Hologram client-runtime, which will receive it from the server in the initial request. Initially we’ll be targeting a specific PCRE version to ensure consistency across the client-side regex behavior.

Thanks for flagging this!

I have an idea for a (probably non-trivial) improvement to the test suite. While porting :erlang.make_tuple/2, I made a mistake and wrote a test checking that making a tuple with size 0 raises an error. This is not true, an empty tuple is returned instead, but the test passed, since my implementation raised an error.

Would it be possible to compare the result of the JS implementation with the result of the actual Erlang function? I assume this would require implementing at least one of term_to_binary and binary_to_term. Does this seem too difficult to be worth the effort?

Allright, I see the problem, fixed it here: https://github.com/bartblast/hologram/commit/482eac4f2fd6e74e2b15de40a221bfe3f3bf3afd

Thank you!

Erlang consistency tests will eventually be automatically transpiled and run on the client. To enable that, we need to port some Erlang functions first (including some from phase 2). For now, matching tests are the simplest and most maintainable way to verify consistency IMO. The same applies to Elixir stdlib tests - they will be transpiled as well eventually to automatically verify consistency.