Suggested solution for two-fer doesn't pass tests.

[tikaro]

Okay, this is a bit odd.

On my environment, the suggested "arrow function" flavor of solution for two-fer is this:

export const twoFer = (name = 'you') => `One for ${name}, one for me.`

However, that solution doesn't actually pass for me. The default value 'you' is not set successfully, and I get, in the failure:

    Expected value to equal:
      "One for you, one for me."
    Received:
      "One for , one for me."

When using arrow functions, it only works if I use ${name = 'you'} in the template string.

I've been Googling -- can I not use default values in arrow functions? and I can't really get a clear answer:
https://stackoverflow.com/questions/34354105/default-parameter-value-in-arrow-function

So I think one of these things are the case:

1. My environment is insufficiently awesome; I need to figure out why I'm unable to use default values in arrow functions during tests.
2. Default values in arrow functions only work sometimes, and we should update the suggested solution so that it doesn't recommend it as a canonical solution.

Any thoughts?

[SleeplessByte]

Default values always work.

Your test suite is likely outdated (and it's passing in '' instead of "nothing/undefined).

[tikaro]

TL:DR; SleeplessByte is correct; I had a stale spec file and didn't know it.

Aha! I see that you changed the test suite ten days ago in PR#649:
exercism/javascript#649

Previously, the spec used an intermediate variable:

const name = '';
expect(twoFer(name)).toEqual("One for you, one for me.")

...which passes '' to twoFer. Since there is a value present (a blank one), the default value is not triggered.

Now, the spec is:

expect(twoFer()).toEqual("One for you, one for me."

...which passes nothing/undefined to twoFer, and so the default value is triggered.

I had gotten it into my head that the "default value" solution was working for the regular function, but not for the arrow function. But I can't reproduce that behavior now; if I re-test with the older version of the spec, both the "regular" flavor and "arrow" flavor fail, as expected.

So this is definitely an issue caused by me running a stale spec.

Normally, I would depend on Git to tell me whether my local files were stale or not, but in this case since we're using a CLI instead of git, I don't have that guardrail. I'll need to remember to make sure that my specs are up to date before getting further into the weeds on language issues :)

Thanks very much for the rapid input, @SleeplessByte !

[SleeplessByte]

A quick sanity check is to first check your solution page at the bottom for a message that it's outdated. If it's not, then at least in the system you're working against the latest first. Now check the test stuite tab. If it doesn't match your local file, you're probably using something outdated locally and need to download again!