feat: add pactffi_log_to_file for consumer/verifier

[YOU54F]

Add ability to log to file, via pactffi_log_to_file

Will go someway to address pact-foundation/pact-js#954

(will need adding into pact-js)

Passed in via an optional param, to getFfiLib which is called by a couple of functions, as an optional param. Wonder if it would be better to have these in an opts object that can take named params.

note, the option used to be called log in pact-js v2 and is moved to deprecated now. should we retain log or use a more descriptive logFile

https://github.com/pact-foundaton/pact-js/tree/9.x.x#constructor

edit

need to add some appropriate tests and refactor based on review comments :)

[TimothyJones]

I think this would be better if it were more explicit - either you have a log file, or you don't. The current form means that it's easy to misread the intermediate functions that don't touch log file.

The guideline I would recommend is that optional parameters exist only at a boundary - and their presence (or not) is handled in the function where they are optional.

[YOU54F]

This is now moved and updated to

export const getFfiLib = (
  logLevel: LogLevel = DEFAULT_LOG_LEVEL,
  logFile: string | undefined = undefined
): typeof ffi => {

[TimothyJones]

What happens if convertLogLevelToFfiLoglevelFilter[logLevel] is undefined?

[TimothyJones]

I think this whole inlined convertLogLevelToFfiLoglevelFilter constant would be better replaced with a switch - then it would introduce no new concepts, and would give you error handling for free.

In general, if you need a really long name for something then it's a good signal that there's an alternative design that would be better.

[YOU54F]

bad things probably 😂 or possibly, I don't know. Makes sense to test all the cases. I just did the bare minimum I could to get logging to file into pact-js when I was in the middle of diving into learning about FFI interfaces, so it is most certainly not the correct way, nor finished, I should move it to a draft and then it can be picked up either by me, or others if they feel inclined

[YOU54F]

If it is undefined, napi will throw an error as we are expecting a numerical argument

Napi::Value PactffiLogToFile(const Napi::CallbackInfo& info) {
   // return: int
   Napi::Env env = info.Env();

  if (info.Length() < 2) {
    throw Napi::Error::New(env, "PactffiLogToFile(envVar) received < 2 arguments");
  }

    if (!info[0].IsString()) {
    throw Napi::Error::New(env, "PactffiLogToFile(envVar) expected a string");
  }

  if (!info[1].IsNumber()) {
    throw Napi::Error::New(env, "PactffiLogToFile(envVar) expected a number");
  }

I've also retained the existing FfiLogLevelFilter[logLevel] rather than needing to add a new function convertLogLevelToFfiLoglevelFilter

[TimothyJones]

Looks alright to me. I left a number of style comments inline.

feat: add pactffi_log_to_file for consumer/verifier

Note that this ends up in the changelog, and this message describes the internals of the change, not how users of pact-js-core will see the change. I think it should describe how the users of pact-js-core will see the change.

Passed in via an optional param, to getFfiLib which is called by a couple of functions, as an optional param. Wonder if it would be better to have these in an opts object that can take named params.

See my comments inline. I don't think it's a good idea to pass optional parameters down to child functions.

I also think that introducing an options object just for this seems unnecessary (and is kind of a workaround for the child function problem). Is there some reason you can't use the same pattern that the rest of the options uses?

[YOU54F]

Thanks for the review dude will address these when I get time :)

[YOU54F]

feat: add pactffi_log_to_file for consumer/verifier

Note that this ends up in the changelog, and this message describes the internals of the change, not how users of pact-js-core will see the change. I think it should describe how the users of pact-js-core will see the change.

Updates to reflect the end user facing argument that has been added, and to which functions they have been added, which is more sensible 👍🏾 thanks for the comment, totally agree

[mefellows]

Is err defined somewhere?

[mefellows]

Are we missing handling the error in this scenario (somebody initialising the FFI more than once with a different log level)?

[mefellows]

Sorry for the late response - just added a couple more comments now, but thanks for the initiative and moving this forward!