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!