exercism / typescript Goto Github PK
View Code? Open in Web Editor NEWExercism exercises in TypeScript.
Home Page: https://exercism.org/tracks/typescript
License: MIT License
Exercism exercises in TypeScript.
Home Page: https://exercism.org/tracks/typescript
License: MIT License
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?
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.
As per #37, port exercise from ecmascript track
As per #37, port exercise from ecmascript track
As per #37, port exercise from ecmascript track
Currently we only test with yarn. We should add test for NPM just in case they diverge.
reference:
#63
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.
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.
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.
Some of the other language tracks I've seen have boilerplate code in their submission files.
Would it be worthwhile to add code like that to our exercises?
As per #37, port exercise from ecmascript track
Note that this is about the exercises (the test suites and code examples), not people's solutions.
Make sure that new exercises has stub files
reference #57
As per #37, port exercise from ecmascript track
As per #37, port exercise from ecmascript track
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:
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.
As per #37, port exercise from ecmascript track
See the contributing guide for the details about the format of an exercise.
The short version is:
example
(case-insensitive) in the filenameThe 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": []
}
]
This means that it will show up on http://exercism.io/languages and http://exercism.io/languages/typescript
test_pattern
in config.json
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.
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.
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.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.
Once the track is live and active, it will often get new contributions.
We've got a few years of experience maintaining language tracks on Exercism. Here's what we have learned:
There's more stuff in the contributing guide, as well. We're working on turning that into better, more focused maintainer documentation.
"active"
to true
in config.json
As per #37, port exercise from ecmascript track
As per #37, port exercise from ecmascript track
Below are exercises implemented in the ES repo that could be easily translated to TS, that haven't already been implemented.
The issue will be closed when all boxes are checked.
As per #37, port exercise from ecmascript track
The current typescript track logo doesn't resemble the actual typescript logo.
As per #37, port exercise from ecmascript track
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?
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?
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:
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.
As per #37, port exercise from ecmascript track
As per #37, port exercise from ecmascript track
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.
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
.
As per #37, port exercise from ecmascript track
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?
As per #37, port exercise from ecmascript track
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! ( :
*/
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:
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.
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 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.
As per #37, port exercise from ecmascript track
Code IDE is an excellent cross platform IDE from Microsoft. We should add instructions on how to set it up to work with TS.
As per #37, port exercise from ecmascript track
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.
Dynamic import would allow us to be able to import the exercise.example
but 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
As per #37, port exercise from ecmascript track
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
Update config to match requirements explained in exercism/discussions#159
As per #37, port exercise from ecmascript track
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.