exercism / typescript

Exercism exercises in TypeScript.

Exercism TypeScript Track

Exercism exercises in TypeScript

This is the TypeScript track, one of the many tracks on exercism. It holds all the exercises that are currently implemented and available for students to complete. The track consists of various core exercises - the ones a student must complete - and each core exercise may unlock various side exercises. You can find this in the config.json.

In version 3 of exercism, the above no longer holds. See the exercism/v3 repository for more information.

Tools

See CONTRIBUTING.md for a list of requirements to contribute to this track. It also has a list of tools you can use, of which the test tool is one of them.

Running the test suite

This runs jest tests for all sample solutions. This does not use the regular way to run jest, because the example solution files must be renamed to be imported correctly into the test files.

yarn test

If the ASSIGNMENT environment variable is set, only that exercise is tested. For example, if you only want to test the two-fer.example.ts for two-fer, you may, depending on your environment, use:

ASSIGNMENT=practice/two-fer yarn test

Running on Windows? Depending on your shell, environment variables are set differently. You can use cross-env to normalize this. The following should work across environments:

yarn dlx cross-env ASSIGNMENT=practice/two-fer yarn test

Related repositories

• Website Copy (Mentor Notes)
• The TypeScript Analyzer
• The TypeScript Representer
• The TypeScript Test Runner

Related JavaScript repositories

A lot of the improvements made to this track and tooling, is also made to the JavaScript track and tooling and vice-versa.

• The JavaScript track
• The JavaScript Analyzer (Automated Code Analysis)
• The JavaScript Representer
• The JavaScript Test Runner

typescript's Issues

Implement grains after TS gains int Type

Grains needs a BigInt Library http://www.2ality.com/2015/04/numbers-math-es6.html

microsoft/TypeScript#4639 (comment)

/**
 * In JavaScript, integers beyond +/- 9007199254740991 cannot be accurately
 * represented. To see this in action, console.log() out the expected number
 * of grains on square #64:
 *
 * console.log(9223372036854775808);
 * // =>       9223372036854776000
 * //                         ^^^^
 *
 * This is because, in JavaScript, integers are represented as 64-bit floating
 * point numbers. If you want to learn more, see:
 *
 * https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number/MAX_SAFE_INTEGER
 * http://stackoverflow.com/questions/307179/what-is-javascripts-highest-integer-value-that-a-number-can-go-to-without-losin
 *
 * So, an accurate solution to this problem requires the use of a
 * "big integer" type. There are multiple ways to use big integer types.
 * We have provided you with BigInteger.js. You can read more about it here:
 *
 * https://github.com/peterolson/BigInteger.js
 * ^--- The "Methods" section of the README will be especially helpful.
 *
 * https://github.com/peterolson/BigInteger.js/blob/master/spec/spec.js
 * ^--- Tests are a good way to understand, in addition to the README.
 *
 * To get you started, this folder has a file of the big-integer module.
 * See its tests in this folder for a quick primer on how to use it! ( :
 */

implement pythagorean triplet

As per #37, port exercise from ecmascript track

implement saddle points

As per #37, port exercise from ecmascript track

Use more "official" logo

The current typescript track logo doesn't resemble the actual typescript logo.

add a NPM pass to CI.

Currently we only test with yarn. We should add test for NPM just in case they diverge.
reference:
#63

implement robot-simulator

As per #37, port exercise from ecmascript track

Exercise "Wordy": README.md doesn't exactly match tests

In README.md the following is written:

If you'd like, handle exponentials.
> What is 2 raised to the 5th power?

But in wordy.tests.ts:

  xit('too advanced', () => {
    const question = 'What is 53 cubed?'
    const problem  = new WordProblem(question)

    expect(problem.answer.bind(problem)).toThrowError( ArgumentError )
  })

README.md doesn't say anything about implementing unary operations. I understand that handling exponentials is considered as optional but in my opinion it is still a bit confusing when tests are so different from description.

npm run test just hangs on jest w/o any feedback

Not really sure what's breaking in my case but when I run what I would think are passing test the command line gives zero feedback

On the hello-world untouched I get errors like:

 [email protected] test /Users/matty/exercism/typescript/hello-world
 tsc --noEmit -p . && jest --no-cache

hello-world.test.ts(11,12): error TS2554: Expected 0 arguments, but got 1.
hello-world.test.ts(15,12): error TS2554: Expected 0 arguments, but got 1.

But lines 11, 15 are xit and therefore shouldn't be called.

If I delete them or satisfy the tests than the command line gives me no feedback

Or if I complete the tests I get no feedback:

class HelloWorld {
    static hello( name='World' ) {
        return `Hello, ${name}!`
    }
}

export default HelloWorld

^ should satisfy all the test but when running npm run test

The terminal just hangs

> [email protected] test /Users/matty/exercism/typescript/hello-world
> tsc --noEmit -p . && jest --no-cache

nothing more... any help?

Add CI for package code

Add a make command that tests to make sure all common files are the same across all problems. This will ensure not edits get introduced in individual problems.

Automate migration of exercises from ECMAScript track

I just added an exercise to this repo from the ECMAScript track. It looks to me like this would be quite an easy process to automate.

Override probot/stale defaults, if necessary

Per the discussion in exercism/discussions#128 we
will be installing the probot/stale integration on the Exercism organization on
April 10th, 2017.

By default, probot will comment on issues that are older than 60 days, warning
that they are stale. If there is no movement in 7 days, the bot will close the issue.
By default, anything with the labels security or pinned will not be closed by
probot.

If you wish to override these settings, create a .github/stale.yml file as described
in https://github.com/probot/stale#usage, and make sure that it is merged
before April 10th.

If the defaults are fine for this repository, then there is nothing further to do.
You may close this issue.

Let the compiler shout at me on typeerrors:

I expect the following snippet to barf at me before even trying to execute the tests:

class HelloWorld {
    static hello(name = "World" : string): number {
        return "Hello, " + name + "!"
    }
}

export default HelloWorld

Instead of barfing, yarn test && yarn lint just complains about string beeing a variable name which clashes with a built in type:

yarn test v0.22.0
$ jest --no-cache
 PASS  ./hello-world.test.ts
  Hello World
    ✓ says hello world with no name (2ms)
    ✓ says hello to bob (1ms)
    ✓ says hello to sally

Test Suites: 1 passed, 1 total
Tests:       3 passed, 3 total
Snapshots:   0 total
Time:        1.063s
Ran all test suites.
Done in 1.79s.
yarn lint v0.22.0
$ tslint '*.ts?(x)'; exit 0

hello-world.ts[2, 35]: variable name clashes with keyword/type
Done in 0.48s.

So currently, in how the tests are run, it seems as if typescript is just another typeless hell around javascript. Therefore the request to do the following:

• Make the compiler fail on type errors (absolute minimum)
• Make the compiler (or the linter) warn or error (the former is totally enough I think) on missing types

Should we add https://github.com/prettier/prettier ?

implement nth-prime

As per #37, port exercise from ecmascript track

implement diamond

As per #37, port exercise from ecmascript track

implement two bucket

As per #37, port exercise from ecmascript track

implement binary-search-tree

As per #37, port exercise from ecmascript track

Consider consistency for the exercises

• Is there a style guide for TypeScript?
• Are these styles encouraged or enforced?
• Are there any conventions that we should adopt on this track for the sake of consistency?
• Can we enforce these?
• Is there a linter? Are there many? Should we use one?
• Is there a common convention for filenames? If not, what should our convention be?

Note that this is about the exercises (the test suites and code examples), not people's solutions.

Track configuration contains improperly locked exercises

In the upcoming release of Configlet v3.8.0, the lint command will now verify that locked exercises meet the unlocked_by criteria, as defined by the track configuration spec:

• Core exercises can not be unlocked by other exercises.
• Non-core exercises can only be unlocked by core exercises.

Before cutting a release of Configlet I am opening issues on all tracks found to contain one or more unlocked_by violations so that maintainers of the track can validate and remedy the violations.

-> The exercise 'prime-factors' is marked as core and unlocked by another exercise. A core exercise should not be unlocked by another. 
-> The exercise 'matrix' is marked as core and unlocked by another exercise. A core exercise should not be unlocked by another. 
-> The exercise 'binary-search-tree' is being unlocked by a non-core exercise. Non-core exercises can only be unlocked by core exercises.

Boilerplate Code in Exercises

Some of the other language tracks I've seen have boilerplate code in their submission files.

Example from the C# track

Would it be worthwhile to add code like that to our exercises?

implement strain

As per #37, port exercise from ecmascript track

Launch Checklist

Step 0: Prep the Repo (@kytrinyx)

• Create the repository
• Create starter issues
• Turn on Travis CI for the track

Step 1: Implement Exercises

• Implement at least 10 problems

See the contributing guide for the details about the format of an exercise.

The short version is:

• a test suite
• an example solution, named with example (case-insensitive) in the filename
• a section in the "exercises" key of the config.json file with the slug, topics, and difficulty level.

The topics can be an empty list, and the difficulty level is from 1 to 10, and can default to 1 until we know more about the exercises.

"exercises": [
  {
    "slug": "hello-world" ,
    "difficulty": 1,
    "topics": []
  }
]

Step 2: Add the Track to Exercism (@kytrinyx)

• Add TypeScript as a submodule in trackler
• Update x-api and deploy

This means that it will show up on http://exercism.io/languages and http://exercism.io/languages/typescript

Step 3: Make the Track Ready for Launch

• Define test_pattern in config.json
• Add a language icon or logo + attribution
• Write documentation
• Find track mentors
• Add track mentors on the site (@kytrinyx)

test_pattern

The exercism.io website links to the exercise implementations, so it needs to know how to recognize the filename(s) for the test suite.

The "test_pattern" value in the config.json file should be a string that can be compiled as a regular expression, and which will match on the file or files that comprise the test suite of an exercise.

If the test filenames contain the word "test" (case insensitive) then the "test_pattern" key can be deleted.

Language Icon and Attribution

We try to create a language icon that has the exercism colors, and is recognizably similar to the language icon. Sometimes this isn't possible due to copyright issues.

The Exercism colors are:

• #D81D4E (pink)
• #212121 (charcoal)

The icon is used throughout the site in order to identify the language track, and to identify code that has been submitted to that track.

See http://exercism.io/languages for all the existing icons.

Icon

If image assets are not your strong suit, just find a reasonable image to start from, along with the information about the licensing, and we'll figure out the colorization thing (I've written some scripts to help me do this part).

The logo should be named icon.png and live under img/ in this repository. If you know how, go ahead and make an SVG as well.

Attribution

The attribution goes in the README.md file.

If the icon we have based this on is not in the public domain, we need to provide information about license and provenance. If we require permission to use and/or change the icon, then we need to obtain that permission before we can use it.

Documentation

The documentation is used in the http://exercism.io/languages/typescript section to help people get started with the track.

The files live in the docs/ directory here in this repository, and gets served to the site via the x-api. It should contain at minimum:

• INSTALLATION.md - about how to get the language set up locally.
• TESTS.md - about how to run the tests for the exercises.

Some nice to haves:

• ABOUT.md - a short, friendly blurb about the language. What types of problems does it solve really well? What is it typically used for?
• LEARNING.md - a few notes about where people might want to go to learn the language from scratch.
• RESOURCES.md - references and other useful resources.

Find Track Mentors

Usually in order to see someone's solution you have to have submitted the exercise yourself. Track mentors can access all of the solutions in a given language. Track mentors can therefore help review solutions that people submit on the website in the beginning when few people have submitted solutions to exercises.

Ideally we should have a handful of people who are willing to check Exercism regularly to give people feedback, in order to start the track off on the right note.

The first track mentor needs to be added manually by @kytrinyx, but after that there's a section in the account where existing track mentors can invite new ones.

The most successful tracks are where each submission receives feedback quickly, preferably within the first 24 hours.

In addition, the most interesting and useful conversations start when reviewers do not direct users to do specific things, but rather ask questions challenging people to think about different aspects of their solution, or explore aspects of the language.

Referencing existing blog posts and style guides seems to work well when making specific recommendations.

Prepare for Open Source Contributions

Once the track is live and active, it will often get new contributions.

• Read the maintainer documentation
• "Watch" the xtypescript repository
• Find a second maintainer

We've got a few years of experience maintaining language tracks on Exercism. Here's what we have learned:

• Maintaining a Track
• Reviewing a Pull Request

There's more stuff in the contributing guide, as well. We're working on turning that into better, more focused maintainer documentation.

Launch!

• Toggle "active" to true in config.json
• Mention it in the next "Behind the Scenes" newsletter (@kytrinyx)

implement clock

As per #37, port exercise from ecmascript track

implement ocr numbers

As per #37, port exercise from ecmascript track

bob: Update to clarify ambiguity regarding shouted questions

TL;DR: the problem specification for the Bob exercise has been updated. Consider updating the test suite for Bob to match. If you decide not to update the exercise, consider overriding description.md.

---

Details

The problem description for the Bob exercise lists four conditions:

• asking a question
• shouting
• remaining silent
• anything else

There's an ambiguity, however, for shouted questions: should they receive the "asking" response or the "shouting" response?

In exercism/problem-specifications#1025 this ambiguity was resolved by adding an additional rule for shouted questions.

If this track uses exercise generators to update test suites based on the canonical-data.json file from problem-specifications, then now would be a good time to regenerate 'bob'. If not, then it will require a manual update to the test case with input "WHAT THE HELL WERE YOU THINKING?".

See the most recent canonical-data.json file for the exact changes.

Remember to regenerate the exercise README after updating the test suite:

configlet generate . --only=bob --spec-path=<path to your local copy of the problem-specifications repository>

You can download the most recent configlet at https://github.com/exercism/configlet/releases/latest if you don't have it.

If, as track maintainers, you decide that you don't want to change the exercise, then please consider copying problem-specifications/exercises/bob/description.md into this track, putting it in exercises/bob/.meta/description.md and updating the description to match the current implementation. This will let us run the configlet README generation without having to worry about the bob README drifting from the implementation.

Add windows CI

HI @kytrinyx

It looks like csharp has support for windows boxes using appveyor under your name.

We just had an issue #45 on windows on this track. Do you have a way to add typescript to the appveyor account so we can run windows tests?

Thanks!

Have exercises that expect non-class implementations?

@masters3d @kytrinyx

I'm looking (and working) through the existing exercises and most of the ones I've looked at so far expect a class or object. One of the stereotypes about TS I've experienced in the wild is that you can't write JS the way you want to anymore, you have to basically write C# in JS. Or "TS is just so OO programmers can feel ok writing JS." Of course that's not true, for example VS Code being written in 100% functional code in TS.

I feel like having some tests expect a function might be helpful in showing for devs new to the language know you don't have to do everything in a class.

I can also see the argument for keeping all the test expectations consistent.

Thoughts?

implement largest-series-product

As per #37, port exercise from ecmascript track

Core libs failing to compile?

Relatively new to JS/TS (and certainly new to the node ecosystem), so bear with me…

npm --install global typescript
npm --install global yarn
mkdir -p exercism/typescript && cd exercism/typescript
exercism fetch typescript
cd hello-world
yarn install
yarn test

gives me a good chunk of errors that would seem to have nothing to do with the exercise:

$ hello-world yarn test
yarn run v1.3.2
$ tsc --noEmit -p . && jest --no-cache
hello-world.test.ts(11,12): error TS2554: Expected 0 arguments, but got 1.
hello-world.test.ts(15,12): error TS2554: Expected 0 arguments, but got 1.
node_modules/typescript/lib/lib.es2015.collection.d.ts(45,11): error TS2428: All declarations of 'WeakMap' must have identical type parameters.
node_modules/typescript/lib/lib.es2015.core.d.ts(21,14): error TS2300: Duplicate identifier 'PropertyKey'.
node_modules/typescript/lib/lib.es2015.iterable.d.ts(157,11): error TS2428: All declarations of 'WeakMap' must have identical type parameters.
node_modules/typescript/lib/lib.es2015.symbol.wellknown.d.ts(133,11): error TS2428: All declarations of 'WeakMap' must have identical type parameters.
../../../node_modules/@types/core-js/index.d.ts(21,14): error TS2300: Duplicate identifier 'PropertyKey'.
../../../node_modules/@types/core-js/index.d.ts(85,5): error TS2687: All declarations of 'name' must have identical modifiers.
../../../node_modules/@types/core-js/index.d.ts(145,5): error TS2403: Subsequent variable declarations must have the same type.  Variable '[Symbol.unscopables]' must be of type '{ copyWithin: boolean; entries: boolean; fill: boolean; find: boolean; findIndex: boolean; keys: ...', but here has type 'any'.
../../../node_modules/@types/core-js/index.d.ts(262,5): error TS2687: All declarations of 'flags' must have identical modifiers.
../../../node_modules/@types/core-js/index.d.ts(276,5): error TS2687: All declarations of 'EPSILON' must have identical modifiers.
../../../node_modules/@types/core-js/index.d.ts(311,5): error TS2687: All declarations of 'MAX_SAFE_INTEGER' must have identical modifiers.
../../../node_modules/@types/core-js/index.d.ts(318,5): error TS2687: All declarations of 'MIN_SAFE_INTEGER' must have identical modifiers.
../../../node_modules/@types/core-js/index.d.ts(457,5): error TS2403: Subsequent variable declarations must have the same type.  Variable '[Symbol.toStringTag]' must be of type '"Symbol"', but here has type 'string'.
../../../node_modules/@types/core-js/index.d.ts(457,5): error TS2687: All declarations of '[Symbol.toStringTag]' must have identical modifiers.
../../../node_modules/@types/core-js/index.d.ts(464,5): error TS2687: All declarations of 'prototype' must have identical modifiers.
../../../node_modules/@types/core-js/index.d.ts(492,5): error TS2687: All declarations of 'hasInstance' must have identical modifiers.
../../../node_modules/@types/core-js/index.d.ts(498,5): error TS2687: All declarations of 'isConcatSpreadable' must have identical modifiers.
../../../node_modules/@types/core-js/index.d.ts(504,5): error TS2687: All declarations of 'iterator' must have identical modifiers.
../../../node_modules/@types/core-js/index.d.ts(510,5): error TS2687: All declarations of 'match' must have identical modifiers.
../../../node_modules/@types/core-js/index.d.ts(516,5): error TS2687: All declarations of 'replace' must have identical modifiers.
../../../node_modules/@types/core-js/index.d.ts(522,5): error TS2687: All declarations of 'search' must have identical modifiers.
../../../node_modules/@types/core-js/index.d.ts(528,5): error TS2687: All declarations of 'species' must have identical modifiers.
../../../node_modules/@types/core-js/index.d.ts(534,5): error TS2687: All declarations of 'split' must have identical modifiers.
../../../node_modules/@types/core-js/index.d.ts(540,5): error TS2687: All declarations of 'toPrimitive' must have identical modifiers.
../../../node_modules/@types/core-js/index.d.ts(546,5): error TS2687: All declarations of 'toStringTag' must have identical modifiers.
../../../node_modules/@types/core-js/index.d.ts(552,5): error TS2687: All declarations of 'unscopables' must have identical modifiers.
../../../node_modules/@types/core-js/index.d.ts(609,5): error TS2403: Subsequent variable declarations must have the same type.  Variable '[Symbol.toStringTag]' must be of type '"Math"', but here has type 'string'.
../../../node_modules/@types/core-js/index.d.ts(609,5): error TS2687: All declarations of '[Symbol.toStringTag]' must have identical modifiers.
../../../node_modules/@types/core-js/index.d.ts(613,5): error TS2403: Subsequent variable declarations must have the same type.  Variable '[Symbol.toStringTag]' must be of type '"JSON"', but here has type 'string'.
../../../node_modules/@types/core-js/index.d.ts(613,5): error TS2687: All declarations of '[Symbol.toStringTag]' must have identical modifiers.
../../../node_modules/@types/core-js/index.d.ts(628,5): error TS2687: All declarations of 'size' must have identical modifiers.
../../../node_modules/@types/core-js/index.d.ts(634,5): error TS2687: All declarations of 'prototype' must have identical modifiers.
../../../node_modules/@types/core-js/index.d.ts(645,5): error TS2687: All declarations of 'size' must have identical modifiers.
../../../node_modules/@types/core-js/index.d.ts(651,5): error TS2687: All declarations of 'prototype' must have identical modifiers.
../../../node_modules/@types/core-js/index.d.ts(656,11): error TS2428: All declarations of 'WeakMap' must have identical type parameters.
../../../node_modules/@types/core-js/index.d.ts(664,27): error TS2344: Type 'K' does not satisfy the constraint 'object'.
../../../node_modules/@types/core-js/index.d.ts(665,53): error TS2344: Type 'K' does not satisfy the constraint 'object'.
../../../node_modules/@types/core-js/index.d.ts(666,5): error TS2403: Subsequent variable declarations must have the same type.  Variable 'prototype' must be of type 'WeakMap<object, any>', but here has type 'WeakMap<any, any>'.
../../../node_modules/@types/core-js/index.d.ts(666,5): error TS2687: All declarations of 'prototype' must have identical modifiers.
../../../node_modules/@types/core-js/index.d.ts(680,5): error TS2403: Subsequent variable declarations must have the same type.  Variable 'prototype' must be of type 'WeakSet<object>', but here has type 'WeakSet<any>'.
../../../node_modules/@types/core-js/index.d.ts(680,5): error TS2687: All declarations of 'prototype' must have identical modifiers.
../../../node_modules/@types/core-js/index.d.ts(692,5): error TS2403: Subsequent variable declarations must have the same type.  Variable 'value' must be of type 'T', but here has type 'T | undefined'.
../../../node_modules/@types/core-js/index.d.ts(692,5): error TS2687: All declarations of 'value' must have identical modifiers.
../../../node_modules/@types/core-js/index.d.ts(804,5): error TS2687: All declarations of 'prototype' must have identical modifiers.
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

versions:

$ tsc -v
Version 2.6.1
$ yarn -v
1.3.2

As the core libs are failing to compile, I can never get the tests to actually pass (even though I can see there are no errors with my file). What's going on, here?

implement sum-of-multiples

As per #37, port exercise from ecmascript track

implement prime factors

As per #37, port exercise from ecmascript track

Need to add global.d.ts?

There will be compilation errors for all test files with use of global variables declare, it, xit, etc...

Should we add a global.d.ts (described here) that specifies these globals, and add them to each of the exercises?

Add documentation about code ide

Code IDE is an excellent cross platform IDE from Microsoft. We should add instructions on how to set it up to work with TS.

Add test for stub exercise-name.ts files to each exercise

Make sure that new exercises has stub files
reference #57

implement series

As per #37, port exercise from ecmascript track

Consider Using VSTS for CI

https://docs.microsoft.com/en-us/vsts/build-release/actions/ci-build-github

VSTS, has linux, mac and windows servers and they now support YAML.

Config Details

Would it be worth fleshing out the config.json file data? Currently every exercise is difficulty: 1 and have empty topics arrays.

I've been considering creating new exercises that would lend themselves to Typescript specific topics, like tsconfig options, typing with keyof and generic types, etc. Exercises like raindrops are good for picking up the basic syntax, but devs like myself could benefit from these. It would be easier for me to find an exercise like that if I could look for it in the topics.

Thoughts?

Add Dynamic Import when avalible.

Dynamic import would allow us to be able to import the exercise.examplebut it that doesn't exist then we could just import exercise. This would help in development.
https://github.com/tc39/proposal-dynamic-import

This would be similar to what we already do in the Objective-C track

#if __has_include("AllergiesExample.h")
# import "AllergiesExample.h"
# else
# import "Allergies.h"
#endif

Update config.json for new track features

Update config to match requirements explained in exercism/discussions#159

implement alphametics

As per #37, port exercise from ecmascript track

Incorrect formatting of package.json version in exercises

ISSUE:

When I fetch a new exercise running npm install fails due to an incorrectly formatted package.json number.

npm WARN Invalid version: "0"

FIX:

Add correctly formatted version number to the package.json files.

Add more exercises from ECMAScript to TypeScript

Below are exercises implemented in the ES repo that could be easily translated to TS, that haven't already been implemented.

• Each new exercise should be submitted in its own PR that references this issue.
• Dependency versions should be consistent with the existing exercises.
• Exercise should be added to config.json
  • For now they can be added with a difficulty of 1, but a specific difficulty would be greatly appreciated.

The issue will be closed when all boxes are checked.

• acronym
• binary-search-tree
• clock
• largest-series-product
• linked-list
• nth-prime
• prime factors
• robot-simulator
• series
• sum-of-multiples

implement kindergarten garden

As per #37, port exercise from ecmascript track

Implement Continuous Integration

Implement a test suite that can run both locally and on Travis CI, that verifies that the example code passes the test suite for each exercise.

Things to consider:

If some tests are marked as skipped or pending in some way, then CI should remove these annotations so that all the tests run against the example, not just the first test.

If we need to rewrite the files in any way, we should copy the exercise to a tmp directory first, so that we don't accidentally end up committing changes that are just for continuous integration or testing purposes.

We should make it possible to test just one exercise at a time, because testing everything can take a while, and very often people are just working on one exercise and will only need to run the full test suite before committing the change.

Ensure no exercise tests are skipped when running `make test`

Some exercise tests are skipped when running make test.

This happens as tests have been marked to be skipped using the xtest function.
Any occurrences of xtest should be replaced with xit.

Add stub exercise-name.ts files to each exercise

When a user first downloads a typescript exercise they have a directory with a test file that imports a ts file, but that ts file doesn't exist.

For example, 'hello-world.test.ts' imports './hello-world.ts' but there is no stub file.

It is an unnecessary step to require users to open the test file for every exercise to check which file they need to create.

implement linked-list

As per #37, port exercise from ecmascript track

Typescript: Using yarn lint will fail with error ' was unexpected at this time

moved from exercism/exercism#3572

Typescript excecism using Windows OS (8.1)

When running yarn lint above error will occur.
error details:

yarn lint v0.24.5                           
$ tslint '*.ts?(x)'; exit 0                 
' was unexpected at this time.              
                                        
E:\exercism\typescript\hamming>  "E:\exercism\typescript\hamming\node_modules\.bin\\node.exe"  "E:\exercism\typescript\hamming\node_modules\.bin\\..\tslint\bin\tslint" '*.ts?(x)'; exit 0
error Command failed with exit code 255.    

changing package.json from

"scripts": {
    "test": "jest --no-cache",
    "lint": "tslint '*.ts?(x)'; exit 0"
}

to

"scripts": {
    "test": "jest --no-cache",
    "lint": "tslint *.ts?(x)"
}

not sure what is the reason behind exit 0

implement connect

As per #37, port exercise from ecmascript track

implement circular buffer

As per #37, port exercise from ecmascript track