We'll need to handle multiple types of data. More specifically, configurations, state, and cache. We'll also need to follow best practices of supported operating systems (currently, Linux and macOS).

• Linux
• macOS

Exercism CLI has an interesting feature: the debug subcommand. It basically outputs a lot of useful information that users can use to provide additional context when they are having issues with the CLI and are opening support requests on GitHub.

Here's an example:

❯ exercism debug

**** Debug Information ****
Exercism CLI Version: 2.4.1
Exercism CLI Latest Release: 2.4.1
OS/Architecture: darwin/amd64
Build OS/Architecture /
Home Dir: /Users/joel
Config File: /Users/joel/.exercism.json
API Key: ********************************
Exercises Directory: /Users/joel/.exercism
Testing API endpoints reachability
	* GitHub API: https://api.github.com/ [connected] 193.444069ms
	* XAPI: http://x.exercism.io [connected] 459.705924ms
	* API: http://exercism.io [connected] 537.524548ms

If you are having trouble and need to file a GitHub issue (https://github.com/exercism/exercism.io/issues) please include this information (except your API key. Keep that private).

May worth having an equivalent like this one.

Version 10 of Node.js (code name Dubnium) has been released! 🎊

To see what happens to your code in Node.js 10, Greenkeeper has created a branch with the following changes:

• Added the new Node.js version to your .travis.yml
• The new Node.js version is in-range for the engines in 1 of your package.json files, so that was left alone

If you’re interested in upgrading this repo to Node.js 10, you can open a PR with these changes. Please note that this issue is just intended as a friendly reminder and the PR as a possible starting point for getting your code running on Node.js 10.

Your Greenkeeper Bot 🌴

Dsafio will download challenges from GitHub and place them somewhere in the user file system. We should describe a file structure to store challenges in users' disks.

Users (and developers) will eventually need to perform operations in their environments (e.g.: warming the registry cache).

dsafio update

Ironically, after researching so much, creating issues to document discoveries, etc., I implemented lib/config and lib/registry without respecting XDG Base Spec.

See #19.

config.get() and config.set() currently throw errors when you pass incorrect parameters, but your interface is promise based. It doesn't make sense. We need to return rejected promises for failed operations instead of throwing errors.

dsafio-config will be responsible for managing user configurations, that will be stored as JSON on a ~/.dsafiorc file.

Tasks

• config module
  • config.get()
    Returns all configurations
    • Unit testing
  • config.set()
    Adds a configuration entry
    • Unit testing
• CLI
  • dsafio config get <key>
    Logs all configurations to STDOUT
  • dsafio config set <key> <value>
    Adds a configuration entry (CLI)

We will use GitHub as our back-end during the alpha launch. A dedicated repository will contain all challenges, and a registry manifest that declares them and their metadata. We'll then need to load this info in the user environment to then be able to use it, as well as caching for reuse.

Source of truth

The challenge manifest contained in the challenges repository should act as the source of truth. However, to avoid sequential network requests we should cache its contents locally.

Environment variables

We should provide ways to hook into the decision of where Dsafio should store info. Besides XDG environment variables, we should support additional variables specific to Dsafio. DSAFIO_CACHE_HOME, DSAFIO_CONFIG_HOME, DSAFIO_DATA_HOME should be used in addition to XDG_* ones.

Memory, disk, and network levels

After loading the challenge registry from GitHub, Dsafio should not perform additional network requests for consecutive reuse. Instead, data should be persisted in memory during the program execution - and it should be used for consecutive library API calls instead of firing network requests. Additionally, a disk cache should be used, and invalidated every seven days (one week).

FYI: As decided in #14, we will be using the XDG Base Dir spec in users' envs.

Configure code quality tools to work with Dsafio.

• https://codebeat.co
• https://codeclimate.com
• https://coveralls.io

We should configure Travis to run standard on our CI.

https://standardjs.com

--

Current list of failures:

• standard ./bin/dsafio-config.js

  ./bin/dsafio-config.js:4:7: Parsing error: The keyword 'package' is reserved
  ./bin/dsafio-config.js:4:15: Multiple spaces found before '='.
  ./bin/dsafio-config.js:5:15: Multiple spaces found before '='.
  ./bin/dsafio-config.js:36:10: Extra semicolon.
  ./bin/dsafio-config.js:54:10: Extra semicolon.
  

• standard ./bin/dsafio.js

  ./bin/dsafio.js:4:7: Parsing error: The keyword 'package' is reserved
  ./bin/dsafio.js:4:15: Multiple spaces found before '='.
  

• standard ./lib/config.js ✅

• standard ./lib/fs-as-promise.js

  ./lib/fs-as-promise.js:1:12: Multiple spaces found before '='.
  

• standard ./lib/registry.js

  ./lib/registry.js:1:15: Multiple spaces found before '='.
  ./lib/registry.js:2:7: 'path' is defined but never used.
  ./lib/registry.js:2:15: Multiple spaces found before '='.
  ./lib/registry.js:3:7: 'util' is defined but never used.
  ./lib/registry.js:3:15: Multiple spaces found before '='.
  ./lib/registry.js:5:15: Multiple spaces found before '='.
  

• standard ./test/lib/config.test.js

  ./test/lib/config.test.js:1:14: Multiple spaces found before '='.
  ./test/lib/config.test.js:2:14: Multiple spaces found before '='.
  ./test/lib/config.test.js:4:14: Multiple spaces found before '='.
  ./test/lib/config.test.js:9:1: 'describe' is not defined.
  ./test/lib/config.test.js:9:36: Block must not be padded by blank lines.
  ./test/lib/config.test.js:11:3: 'it' is not defined.
  ./test/lib/config.test.js:13:3: 'describe' is not defined.
  ./test/lib/config.test.js:13:33: Block must not be padded by blank lines.
  ./test/lib/config.test.js:15:5: 'beforeEach' is not defined.
  ./test/lib/config.test.js:19:5: 'afterEach' is not defined.
  ./test/lib/config.test.js:21:5: 'it' is not defined.
  ./test/lib/config.test.js:23:5: 'it' is not defined.
  ./test/lib/config.test.js:30:5: 'it' is not defined.
  ./test/lib/config.test.js:36:5: 'it' is not defined.
  ./test/lib/config.test.js:52:3: Block must not be padded by blank lines.
  ./test/lib/config.test.js:54:3: 'describe' is not defined.
  ./test/lib/config.test.js:54:33: Block must not be padded by blank lines.
  ./test/lib/config.test.js:56:5: 'beforeEach' is not defined.
  ./test/lib/config.test.js:60:5: 'afterEach' is not defined.
  ./test/lib/config.test.js:65:5: 'it' is not defined.
  ./test/lib/config.test.js:67:5: 'it' is not defined.
  ./test/lib/config.test.js:71:5: 'it' is not defined.
  ./test/lib/config.test.js:75:5: 'it' is not defined.
  ./test/lib/config.test.js:81:5: 'it' is not defined.
  ./test/lib/config.test.js:89:3: Block must not be padded by blank lines.
  ./test/lib/config.test.js:91:1: Block must not be padded by blank lines.
  

• standard ./test/lib/registry.test.js

  ./test/lib/registry.test.js:1:16: Multiple spaces found before '='.
  ./test/lib/registry.test.js:2:16: Multiple spaces found before '='.
  ./test/lib/registry.test.js:3:16: Multiple spaces found before '='.
  ./test/lib/registry.test.js:8:1: 'describe' is not defined.
  ./test/lib/registry.test.js:8:38: Block must not be padded by blank lines.
  ./test/lib/registry.test.js:10:3: 'it' is not defined.
  ./test/lib/registry.test.js:12:3: 'describe' is not defined.
  ./test/lib/registry.test.js:12:33: Block must not be padded by blank lines.
  ./test/lib/registry.test.js:14:5: 'beforeEach' is not defined.
  ./test/lib/registry.test.js:21:5: 'afterEach' is not defined.
  ./test/lib/registry.test.js:26:5: 'it' is not defined.
  ./test/lib/registry.test.js:28:5: 'it' is not defined.
  ./test/lib/registry.test.js:35:5: 'it' is not defined.
  ./test/lib/registry.test.js:41:5: 'it' is not defined.
  ./test/lib/registry.test.js:55:3: Block must not be padded by blank lines.
  ./test/lib/registry.test.js:57:1: Block must not be padded by blank lines.
  

Version 3.2.0 of debug was just published.

This version is covered by your current version range and after updating it in your project the build failed.

debug is a direct dependency of this project, and it is very likely causing it to break. If other packages depend on yours, this update is probably also breaking those in turn.

Your Greenkeeper Bot 🌴

Dsafio needs a proper contribution manual, explaining its core mission, architecture and components, as well as coding standards, contribution flow, etc.

Dsafio provides coding challenges that let people practice their programming skills. We must discuss and decide about the flow our users will be using, how the architecture will look like, as well as the tooling used to test users' solutions.

Flow

Initial setup

1. User installs Dsafio CLI: npm i -g dsafio
2. User runs a dsafio command or subcommand for the first time
3. dsafio detects a new environment, starts the setup wizard and:
   1. setup user data
   2. download the challenge registry
   3. setup working directory
   4. download the first challenge

The loop

1. User codes a solution that passes all tests
2. User runs dsafio test to run tests and:
   • returns to step 1 on failure
   • receives a congratulatory message that suggests him/her to download the next challenge
3. User run dsafio next and it
   1. uses the registry data to identify the next challenge
   2. download the next challenge and setup the working directory

Architecture

I'm looking at GitHub API v3 and thinking in a way to keep just a static registry of challenges as a Git repository. Since we will not be storing user information during the alpha stage the registry can be just a static JSON file present in a GitHub repository.

The Repository Contents methods allow the recovery of specific files from a given repository. With this capability we could:

• load a static registry of challenges (e.g.: registry.json)
• download specific challenges described in the registry (e.g.: challenges/hello-world)
• build the challenges track based on the order of disposal in the registry
• keep the user progress locally

It could solve the back-end needs in a very sophisticated way. GitHub as back-end = 🤘😎

Tooling

We can start with Mocha as unit testing tool but suggestions are welcome. We are prioritizing smaller download sizes and friendly output messages, but we still have a lot to discuss and learn on this matter.

dsafio-get and dsafio-set have different signatures, and commander doesn't provide a good support for branching subcommands with different signatures. An Express style getter/setter for configuration seems to be a better approach to this problem.

dsafio-config has the following signature:

dsafio config <get|set> [key=value...]

It should split into two distinguished commands with its own signatures:

dsafio get [key...]

dsafio set <key> <value>

References:

• Promise object page on MDN
• commander option parsing
• commander subcommands

A ENOENT error is thrown when an user tries to run dsafio config get or dsafio config set subcommands without a .dsafiorc present:

❯ dsafio config get
error { Error: ENOENT: no such file or directory, open '<$HOME>/.dsafiorc'
  errno: -2,
  code: 'ENOENT',
  syscall: 'open',
  path: '<$HOME>/.dsafiorc' }

Dsafio is an educational project from Brazilians, for Brazilians. However, the software development industry chose English as Lingua Franca to collaborate. We need to decide which language we'll use to collaborate on Dsafio.

PS: we are NOT discussing which language our content will be available on. It will be Brazilian Portuguese. We are discussing which language we'll use during development - including source code, documentation, task descriptions and technical discussions.

PS: I'll be using English to write issues and documentation for now.

I just tested Buddy and it's incredibly fast! A build of Dsafio ran in 9s, in contrast to Travis which generally runs in ~1min. Buddy has a free plan that allows a project to run 120 builds per month, so it can easily fulfill Dsafio's needs.

And they have badges! 😄 https://buddy.works/blog/introducing-badges-pipelines-branch

The prototype version of Dsafio will not have a dedicated back-end. We will not persist user data in servers; instead, we'll keep a "database" in the user environment with cached information like the challenges registry, which challenges have been solved, and any other information that isn't suitable to be stored as configuration in users' .dsafiorc file.

Things to discuss:

• Where should we store data?
• How should we organize challenges in users' environments?

Where should we store data?

Discussed in #19.

How should we organize challenges in users' environments?

Being discussed in #20.

We could namespace the file system like <prefix>/<challenge-name> (approach used by Exercism):

- <dsafio-prefix>/ (e.g.: ~/dsafio)
  - <challenge-name>/
    - index.js
    - readme.md
    - test.js

We could also keep present only one file at the time:

- <dsafio-prefix>/ (e.g.: ~/dsafio)
  - index.js
  - readme.md
  - test.js

We need integration tests to make sure the communication between our code and the GitHub REST API works as expected.

• Write integration tests
• Be able to enable/disable integration tests (env variables?)
• Support for custom API tokens (might become a separated issue)

PS: this issue needs planning before implementation.

We should limit what gets published when npm publish is ran. Today everything in the repository is published to the npm, including tests and configuration files that aren't really part source code.

The files entry on package.json should be used to limit the publishing to:

• readme.md
• package.json and package-lock.json
• all files in ./bin
• all files in ./lib

Command used to setup the user local environment for Dsafio.