Take the Allergies exercise from xjavascript.

There are several libraries/platforms that support ECMAScript 2015, but they don't cover all the features. Options are:

• NodeJS v4, that covers 51%
• Babel, that covers 79%
• Traceur, that covers 59%. This is what the language track currently uses.

Babel seems the best option.

@kytrinyx, how could more people be involved on this discussion?

I will port this from the JS track.

Test descriptions are written in terms of binary numbers, but test implementations are written in terms of decimal numbers.

Write tests with hexadecimal numbers and change test descriptions. It will help users to relate both.

I will port from JS track.

I will port this from the JS track.

Todos

• Build a sane test workflow.
• Clean up exercise.

In order to launch we should have:

• ECMAScript as a submodule in x-api
• at least 10 problems
• a "how to get started" topic in the help repo repo (app/pages/languages/getting-started-with-ecmascript.md)
• one to a handful of people willing to check exercism regularly (daily?) for nitpicks to ensure that the track gets off on the right foot
• add track implementors and other designated nitpickers as mentors to the track
• toggle "active" to true in config.json

Some tracks have been more successful than others, and I believe the key features of the successful tracks are:

• Each submission receives feedback quickly, preferably within the first 24 hours.
• The nitpicks do not direct users to do specific things, but rather ask questions challenging people to think about different aspects of their solution, or explore new aspects of the language.

For more about contributing to language tracks on exercism, check out the Problem API Contributing guide: https://github.com/exercism/x-api/blob/master/CONTRIBUTING.md

I struggled a little bit while running my code for the palindrome-products assignment, so I was wondering if there could be a better way to run them.

I was thinking of having a package.json file (as if the assignment was a NodeJS module) and a gulpfile.js file, to have all the work automated in a Gulp script.

But I'm not sure if this is compatible with exercism's philosophy. The exercism user must have installed NodeJS (I think this is acceptable) and she must first install gulp-cli tool so that she can run then the Gulp script. Then, for each assignment, the idea is that the user has just to run a npm install command at the beginning, and npm test or gulp test every time she wants to run her tests.

If this way of working on ecmascript assignments is ok, I'll implement it on the existing one, palindrome-products, and I'll make a pull request.

I will port this from the JS track.

The user-facing description of the language track still refers to Traceur:

http://help.exercism.io/getting-started-with-ecmascript.html

We should update that. Where does the helpfile live?

@rchavarria this test imports BigInt but doesn't use it, instead requiring the student return results as strings. It looks like the JS track was edited to make the same change.

It seems like in both cases grains.spec.js should use BigInt or remove the import.

What would you like to do?

So, I proposed to a team member that he should try using default params in hello-world. However, it doesn't work because the first test passes an empty string rather than an undefined value. Here's his solution: http://exercism.io/submissions/35fced9768e840df98afa4b85fbfac56

Should the first test be changed to pass an undefined value to allow the use of default params? EG
current:

  it('says hello world with no name', () => {
    expect(helloWorld.hello('')).toEqual('Hello, World!');
  });

maybe?:

  it('says hello world with no name', () => {
    expect(helloWorld.hello()).toEqual('Hello, World!');
  });

@kytrinyx @rchavarria what do you think? What do the other tracks do with empty but not undefined values?

This was recently changed in the JavaScript track, and it feels a lot cleaner: exercism/exercism#2581

I will port this from the JS track.

Take it from xjavascript track

A simple icon was provided in PR exercism/exercism.io#2583.

Improve it. An option can be a ECMAScript version of the JS shield in that PR.

porting binary from JS track. PR #74

@rchavarria, I figured I'd let you take the one after scrabble-score (roman-numerals) and I'll take the one after that : circular-buffer

Port it from xjavascript track

I will port the exercise 'Strain' from the JS track to this track.

OK, maybe one more. I'll do this one!

I made a really stupid choice a while back to commit the cross-compiled
binaries for configlet (the tool that sanity-checks the config.json
against the implemented problems) into the repository itself.

Those binaries are HUGE, and every time they change the entire 4 or 5 megs get
recommitted. This means that cloning the repository takes a ridiculously long
time.

I've added a script that can be run on travis to grab the latest release from
the configlet repository (bin/fetch-configlet), and travis is set up to run
this now instead of using the committed binary.

I would really like to thoroughly delete the binaries from the entire git
history, but this will break all the existing clones and forks.

The commands I would run are:

# ensure this happens on an up-to-date master
git checkout master && git fetch origin && git reset --hard origin/master

# delete from history
git filter-branch --index-filter 'git rm -r --cached --ignore-unmatch bin/configlet-*' --prune-empty

# clean up
rm -rf .git/refs/original/
git reflog expire --all
git gc --aggressive --prune

# push up the new master, force override existing master branch
git push -fu origin master

If we do this everyone who has a fork will need to make sure that their master
is reset to the new upstream master:

git checkout master
git fetch upstream master
git reset --hard upstream/master
git push -fu origin master

We can at-mention (@) all the contributors and everyone who has a fork here in this
issue if we decide to do it.

The important question though, is: Is it worth doing?

Do you have any other suggestions of how to make sure this doesn't confuse people and break their
repository if we do proceed with this change?

The contents of the SETUP.md file gets included in
the README.md that gets delivered when a user runs the exercism fetch
command from their terminal.

At the very minimum, it should contain a link to the relevant
language-specific documentation on
help.exercism.io.

It would also be useful to explain in a generic way how to run the tests.
Remember that this file will be included with all the problems, so it gets
confusing if we refer to specific problems or files.

Some languages have very particular needs in terms of the solution: nested
directories, specific files, etc. If this is the case here, then it would be
useful to explain what is expected.

Thanks, @tejasbubane for suggesting that we add this documentation everywhere.
See exercism.io#2198.

cf. Issue #37

It seems Babel is a better choice for transpiling ES2015 code to ES5.

Port it from xjavascript

Add an ABOUT.md file in the path specified in exercism/x-common#110 to show a new section in the language track: About.

I will port this from the JS track

See http://help.exercism.io/getting-started-with-go.html as an example.

If appropriate, suggest a linter (see exercism/docs#54).

When I review code submissions in exercism.io I miss some syntax highlighting. Is this something that can be fixed in the language track?

Just highlighting it just as JavaScript code would be the fastest fix and maybe enough for now.

Additionally, next to the submission title, there is a yellow circle. In the JavaScript language track it shows a "JS" text. Could it show some text for ECMAScript? "ES" or other customized icon?

The last several PRs have left config.json out of sync with the JS track. I will put in a PR to fix that.

Currently, the main gulpfile.js file is just copied into each individual exercise when running the make command at development time. Keeping them synchronized by copying is not the best way to remove duplication.

Figure out a better way to share code between all gulpfile.js files and remove duplication.

I will port this exercise from the JS track.

Currently, there is no way to keep synchronized the main package.json file with the same file for individual exercises. It's mandatory to keep synchronized at least the dependencies section, because all exercises will use the same NodeJS packages to let users lint, transpile and run code tests.

Figure out a way to keep the synchronization.

I will port this from the JS track

I will port this from the JS track.

I will port this from the JS track.

Adapt JavaScript exercise, roman-numerals, to this track.

Take it from the JavaScript track

I will port this from the JS track.

I will port this from the JS track.

I will port this from the JS track.

I will tackle this one!

I will port this from the JS track.

See issue exercism/exercism#2092 for an overview of operation welcome contributors.

Provide instructions on how to contribute patches to the exercism test suites
and examples: dependencies, running the tests, what gets tested on Travis-CI,
etc.

The contributing document
in the x-api repository describes how all the language tracks are put
together, as well as details about the common metadata, and high-level
information about contributing to existing problems, or adding new problems.

The README here should be language-specific, and can point to the contributing
guide for more context.

From the OpenHatch guide:

Here are common elements of setting up a development environment you’ll want your guide to address:

Preparing their computer
Make sure they’re familiar with their operating system’s tools, such as the terminal/command prompt. You can do this by linking to a tutorial and asking contributors to make sure they understand it. There are usually great tutorials already out there - OpenHatch’s command line tutorial can be found here.
If contributors need to set up a virtual environment, access a virtual machine, or download a specific development kit, give them instructions on how to do so.
List any dependencies needed to run your project, and how to install them. If there are good installation guides for those dependencies, link to them.

Downloading the source
Give detailed instructions on how to download the source of the project, including common missteps or obstacles.

How to view/test changes
Give instructions on how to view and test the changes they’ve made. This may vary depending on what they’ve changed, but do your best to cover common changes. This can be as simple as viewing an html document in a browser, but may be more complicated.

Installation will often differ depending on the operating system of the contributor. You will probably need to create separate instructions in various parts of your guide for Windows, Mac and Linux users. If you only want to support development on a single operating system, make sure that is clear to users, ideally in the top-level documentation.

As discussed in exercism/xjavascript#101 and exercism/xjavascript#26, ESLint seems to be a good tool to lint JavaScript and ECMAScript source code.

Add it and configure it to lint source code at development time.

A thought...I wonder if it was short-sighted of me to suggest the name xecmascript6 when in fact, traceur is already adding ES7+ features that can be used now.

exercism/xjavascript PR#125 adds a new test to the problem. It would be nice to add a similar one to this repository.

@kytrinyx whenever there is more than one pending PR for a new exercise, merging one creates a conflict in config.json. Not a huge deal, but it does complicate splitting up the work of adding new exercises.

Is there a way to remove the dependency on problems[], maybe by building the list dynamically from the directory names or putting a config.json file in each exercise directory?

I will port this from the JS track