Port missing exercises from JavaScript to EcmaScript track

[matthewmorgan]

After more conversation with @kytrinyx and others, I've prepared a few things for deprecating the current JS track.

For V2, the EcmaScript track will become the "new" JavaScript track. Users' submissions will be migrated as part of the process.

Katrina's notes on the migration process:

We will take the v1 site down in order to launch v2.
The site will have to be offline for 24-48 hours, because we have a massive data migration that we need to do.

During that time, we can:

• rename https://github.com/exercism/javascript to https://github.com/exercism/DEPRECATED.javascript
• set active: false in the config of DEPRECATED.javascript
• rename https://github.com/exercism/ecmascript to https://github.com/exercism/javascript
• delete the GitHub team exercism/javascript
• rename the GitHub team exercism/ecmascript to exercism/javascript

In the meantime, I've closed all open issues and PRs on the JS track as wontfix, leaving one issue open stating the track will be deprecated. I have also updated the README to alert users to the deprecation.

On this track, we need to

• [] identify any exercises that exist in the current JS track but not in this one
• [] open issues to port those exercises

@tejasbubane @joelwallis ( @jackhughesweb ? ) would any of you care to take on the audit of missing exercises? That step seems to need to be done first.

[matthewmorgan]

On #412 @joelwallis wrote:

Matt,

I could help on it. Should I compare the implementations too? EcmaScropt
and JavaScript tracks have different ways to implement the exercises. The
first one uses way more classes while the second one uses functions and
constructors. How will we proceed with it? Is it something relevant?

@joelwallis I did discuss with @kytrinyx the differences in implementation syntax between the JS track and the ES track for a given exercise.

I think that changing the API of the tests and example of a newly ported exercise could be at the discretion of the implementer. Function or POJO based solutions are just as legitimate in ES6 as class-based ones. For sure we would want to update the module syntax and the test syntax (it vs test) to conform to the ES track conventions.

As far as worrying about an existing exercise that is implemented in both places, but with a different API, the ES one should take precedence and remain as-is. This may break a user's existing solution, but this happens frequently with normal changes and improvements to exercise code anyway.

The intention is that a user's existing solutions will be migrated to the matching exercise in the new track, though it may not exactly match because of potential API differences. The code will still be there, and they could update their solution if they want to.

Let me know if this sounds OK to you, or if you have any objections or questions.

Thanks!

[tejasbubane]

@matthewmorgan I diffed existing exercises in both tracks and this is what I see:

Exercises in javascript track but not in ecmascript

• forth
• point-mutations
• rational-numbers
• reverse-string
• variable-length-quantity
• zipper

Exercises in ecmascript track but not in javascript

• complex-numbers
• house
• react
• spiral-matrix
• word-search

Ref: https://gist.github.com/tejasbubane/13d5fbb3db0da6f1ea047e27d704e3a2

How do we proceed about these differences? I guess we will have to port over missing exercises from javascript track to ecmascript. Otherwise the data migration will not be consistent.

[matthewmorgan]

@tejasbubane thanks for that list. Yes, we are going to port any exercises in JS but not in ES to ES. So, your first list is the one we need to use.

I feel like that list is short enough that we don't need separate issues for each one, but just a checklist here:

Exercises to port from JavaScript track to EcmaScript track

• forth
• point-mutations
• rational-numbers
• reverse-string
• variable-length-quantity
• zipper

Let's check each of these off as the PRs are merged, and then we can close this issue.

@tejasbubane @joelwallis if each of you can take a couple of these, I can take the remaining two. Would you mind picking and assigning the exercises to yourself in an empty PR?

[joeljuca]

@matthewmorgan sounds like a plan. I'll dibs the two first ones (forth and point-mutations).

[matthewmorgan]

@joelwallis awesome! A couple of things that came up with @gavinhenderson's PR:

• need to change UUID, even though the track is different.
• don't forget to update README to refer to EcmaScript rather than JS for links and other instructions.

I had neglected to call these out explicitly.

[tejasbubane]

I'll dibs on variable-length-quantity and zipper.

[matthewmorgan]

OK, I guess that leaves rational-numbers for me. I will take that one.

[matthewmorgan]

@tejasbubane @joelwallis how are your PRs coming? I could do a couple of these myself this weekend. Migration is currently underway, so I think we should wrap this up if possible.

[joeljuca]

Hey Matt,

I'm unable to implement my two exercises this weekend. I started working on the fourth yesterday, but I couldn't progress on it. I never worked with stack-based languages, so I have to learn how they work before implementing it.

If you want, get this one from my plate. I'll be able to work on something this Monday, so I can get the point-mutations done.

[matthewmorgan]

OK, got it-- I will give forth a look!

[matthewmorgan]

OK, forth is merged. @tejasbubane let me know if I can take anything off your plate and help get this over the finish line.

[matthewmorgan]

@tejasbubane @joelwallis it looks like the V2 migration has happened. I don't know that this adds any urgency to getting those exercises ported, but let me know if you will be able to finish this in the next day or two.

"I don't have time this week" is a perfectly acceptable answer, I just don't want to step on anyone's toes. This seems like an important loose end to me, and I am willing and able to finish porting the three exercises if need be.

By the way, @joelwallis, your earlier comment about the forth exercise made me think I should have offered my process: when I do these ports, I rarely try to understand the problem at any deep level.

My process:

• Copy the JS exercise config block to config.json and update the UUID.
• Create a new directory for the ported exercise.
• Copy the spec file and the example file from JS.
• Update the syntax in the specfile
  -- require to import
  -- xit to xtest
  -- function() {} to () =>
  -- var to const, or let where needed.
  -- etc.
• Update the syntax in the example file
  -- Function to class
  -- var to const or let
  -- module.exports to export
  -- etc.
• Update README for ES specifics

I don't try to add or improve anything. I leave that for a future PR.

Maybe the above approach will be helpful to you!

[joeljuca]

Hi @matthewmorgan,

Unfortunately, I'm not finding time this week to work on this issue. Feel free to take point-mutations from my plate. Thank you very much for stepping forward to offer some help.

[matthewmorgan]

Done.

[matthewmorgan]

@tejasbubane Since you hadn't commented on this in a few weeks, I went ahead and finished the last two that needed to be done. You are welcome to improve the exercise implementations if you are so inclined!

[tejasbubane]

Sorry @matthewmorgan, I was busy this week and somehow missed these notifications :(

[matthewmorgan]

Not a problem at all! I just didn't want you to be disappointed if you were fired up to do the work!