DEV Community: André Varandas

What VS Code extensions am I using?

André Varandas — Sun, 14 Mar 2021 20:48:54 +0000

I like to keep VS Code lightweight as much as possible, therefore I don't have that many extensions - only the ones that are really cannot live without.

The more extensions you have, the more memory it will consume, the more time to boot up vs code.

I should also add that my main editor is not visual studio code but Webstorm. I mainly use VS Code for small edits on some JSON or small JavaScript files. Sometimes I may also use VS Code for starting up small side projects, when I want to try something new or some ideas from a blog post I just read.

I love VS Code and I like to keep it ready for hacking. 😊

ESLint - This one integrates ESLint into VS Code.
EditorConfig for VS Code - Adds support for .editorconfig files.
EditorConfigGenerator - I am lazy enough I can't open a new tab and search for a good default .editorconfig so I use this extension to generate the defaults for me.
markdownlint - As I'm usually editting a lot of .md files, this extension informs me about lint errors.
npm - Adds some nice npm scripts options to the command pallete.
npm Intellisense - Adds intellisense on import statements.
Prettier - Code formatter - I really like prettier defaults.
Vetur - Vue tools for VS Code. Most of the time I'm working with Vue, this extension adds a lot of useful snippets as well as syntax highlighting.
GitLens - Git supercharged - Helps to visualize code changes.

And that's it! This is the minimum I need to make VS Code work just as I want for my needs. I used to have a lot more, I even lost track of them, until VS became so slow, I had to revise all of them, removing all the non essential ones.

What are the VS Code extensions you can't live without?

Thanks for reading 👋

Photo by John Barkiple on Unsplash

Setting up continuous Integration

André Varandas — Tue, 18 Aug 2020 11:59:02 +0000

Repository for this part is available on git branch master

AndreVarandas / mood-sentences

✨ Mood sentences

Preparation

In this part of our tutorial series, we will add CI (Continuous Integration) with https://travis-ci.org/. It's free for public repositories.

If you've also made yours private, now is the time to make your Github project public before going any further. Simply click on settings -> Scroll down to Danger Zone and click on change visibility to public.

npm account setup

It's also a good time to make sure our npm account is properly configured/created. Go to https://www.npmjs.com/ and create or login to your account.

Click on your profile avatar (top right) and choose "Add organization". I'm using my own name for mine (@varandas), but you can choose whatever you'd like.

Pushing packages to an organization, makes them "scoped". In my case, my package full name will be "@varandas/mood-sentences". This makes npm cleaner and avoids clashing with already existing package names.

We will also need to update our package.json file. In the first line, we have a "name" property, that I've updated to:

"name": "@varandas/mood-sentences",

Travis configuration

Head to https://travis-ci.org/account/repositories login or create an account with your github profile and click on sync account button, right under your profile picture on the top left, for travis to fetch your repositories. Once that is done, under Legacy Services Integration enter the name of your repository. Once it shows in the list, click on the toggle to enable travis for our repository.

Now travis has permissions to access our repository.

We need to add a special file at the root of our project named .travis.yml. Later, when we push our code, travis CI will look for this configuration file - executing our instructions.

sudo: false
language: node_js
branches:
  only:
    - master
notifications:
  email: false
node_js:
  - '10.20.1' # I've added the same version as in my machine
script:
  - npm run lint
  - npm install -g codecov # Tool for code coverage
  - npm run test
  - codecov -f coverage/*.json
after_success:
  - codecov
  - npm run semantic-release
branches:
  except:
    - "/^v\\d+\\.\\d+\\.\\d+$/"

We have defined a set of instructions, such as which branch to build, nodeJS version, scripts to run, and what to do after success. If for some reason our lint or tests fail, the build will also fail - and no version is generated.

Semantic release

Speaking about version generation, you might have noticed the script npm run semantic-release. We are missing this script - but we will add it shortly.

Semantic Release is a tool for automatic package release and versioning.

As seen on their website:

semantic-release automates the whole package release workflow including: determining the next version number, generating the release notes, and publishing the package.

Fortunately, they also provide an awesome package that will help us getting everything configured. If you have "npx" please open the terminal at the root folder and run npx semantic-release-cli setup.

If "npx" is not available, install the tool globaly with npm install -g semantic-release-cli and then run semantic-release-cli setup.

The cli will prompt you for your Github and npm username and credentials. The tool will use them to setup the required access tokens, so travis will be able to push your code to npm.

Your package.json file should now include a new "semantic-release" script a few dependencies and an updated value for version property.

Now we should also update the "main" property of our package.json and include a publish config key with the access type. As to use npm for free packages must be public, this configuration must be present.

...
  "main": "src/index.js",
  "publishConfig": {
    "access": "public"
  },
...

And finally run npm install just to update our package-lock.json.

Release

With this, we have everything ready to create a new commit and push our changes. Once we do this, travis will now load our project, build, create a new release, tag, and push it to the previous organization we created earlier on npm.

Run git add -A and npm run commit to create a new commit. Note that only some commit types generate a new release. I recommend picking the "feature" for this commit.

You can keep track of travis build by going to https://travis-ci.org/dashboard/builds and clicking on your repository name.

If everything goes as expected, your package should now be live! You can see it in your dashboard https://www.npmjs.com click on your profile -> packages, then on the left click on your organization name, and voila 🎉.

Congratulations! Your first package is live!

You can test it right away by installing it locally with:

npm install --save @YOUR_ORGANIZATION/mood-sentences or test mine with npm install --save @varandas/mood-sentences.

You can check this finished chapter on github https://github.com/AndreVarandas/mood-sentences/tree/master

Thanks for reading!
Happy coding 🎉

Writing tests

André Varandas — Tue, 18 Aug 2020 11:58:09 +0000

Repository for this part is available on git branch writing-tests

AndreVarandas / mood-sentences

✨ Mood sentences

Writing tests

Our simple package is almost ready. We only need to add some tests. As the package is small, it should be pretty straight forward.

Let's start by creating a special folder under src named __tests__. Then add a new file and name it index.test.js.

In this file, we will write our tests. These will be automatically picked up by jest thanks to the configuration we added earlier to the jestconfig.json file.

As we are going to use special variables, in order to stop our linter from complaining, we should extend our .eslintrc.js file. Start by adding the jest plugin npm i --save-dev eslint-plugin-jest.

Then modify the .eslintrc.js file to include it:

module.exports = {
  env: {
    browser: true,
    es2020: true,
    node: true,
    jest: true // add this line
  },
  extends: [
    'standard'
  ],
  parserOptions: {
    ecmaVersion: 11,
    sourceType: 'module'
  },
  rules: {
  }
}

Now we should be able to write our tests without any lint errors.

I usually try to test all the exported methods - so I can have some confidence that the consumer is getting the expected results. In our case, we want to test:

module.exports = {
  all: moods,
  anger: moods.anger,
  boredom: moods.boredom,
  excitement: moods.excitement,
  happiness: moods.happiness,
  getRandom,
  list
}

Testing all of these properties and methods will give us 100% of code coverage. Pretty neat!

Our test will only have a "test suite" which is basically defined by the keyword describe. Inside this test suite, we will add our tests. We can start by adding a test to check if the property .all returns, in fact, all the available mood sentences:

// Import our package
const Moods = require('../index')

describe('mood-sentences', () => {
  test('.all should return all sentences', () => {
    const all = require('../mood-sentences.json')
    expect(Moods.all).toMatchObject(all)
  })
})

As our property Moods.all is nothing more than the contents of the json file, this way we can check that they match.

Let's continue adding all the other properties that should match the json file contents.

const Moods = require('../index')

describe('mood-sentences', () => {
  test('.all should return all sentences', () => {
    const all = require('../mood-sentences.json')
    expect(Moods.all).toMatchObject(all)
  })

  test('.anger should return all anger sentences', () => {
    const { anger } = require('../mood-sentences.json')
    expect(Moods.anger).toMatchObject(anger)
  })

  test('.boredom should return all boredom sentences', () => {
    const { boredom } = require('../mood-sentences.json')
    expect(Moods.boredom).toMatchObject(boredom)
  })

  test('.excitement should return all excitement sentences', () => {
    const { excitement } = require('../mood-sentences.json')
    expect(Moods.excitement).toMatchObject(excitement)
  })

  test('.happiness should return all happiness sentences', () => {
    const { happiness } = require('../mood-sentences.json')
    expect(Moods.happiness).toMatchObject(happiness)
  })
})

Nothing too fancy, but it assures us that the json contents are being used.

Next, we want to test the .list property that should return all the available moods. It is used to get random sentences for a mood.

  test('.list should return a list of available moods', () => {
    // Get the json file moods
    const moods = require('../mood-sentences.json')

    // Get all the values defined in the .list property ['anger', 'excitement'...]
    const values = Object.values(Moods.list).sort()

    // Get the json keys ['anger', 'excitement'...]
    const expected = Object.keys(moods).sort()

    expect(values).toEqual(expected)
  })

This way we make sure that all the values in the .list property actually exist and match the keys in the json file. If we decide to add one more mood to the json file, we would also have to add a key->value to our list enum.

Lastly, we need to have a test for the .getRandom method.

 test('.random() should return a random sentence for a mood', () => {
    const randomSentence = Moods.getRandom(Moods.list.HAPPINESS)

    expect(Moods.happiness).toContain(randomSentence)
  })

  // Handle errors (empty call, or non existing mood)
  test('.random() without mood, it throws an error', () => {
    try {
      Moods.getRandom()
    } catch (error) {
      expect(error).toBeInstanceOf(Error)
      expect(error).toHaveProperty('message', 'Requested mood "undefined" is not in the moods list!')
    }
  })

With our last test, we should have reached 100% coverage!
Now we can test it, using the script we previously defined in our package.json file: npm run test.

You should get a result like the following:

With this, we have achieved 100% coverage. It's not hard on such a small library. 🤓

We should also add a new pre-push hook to husky, so it will run our tests before pushing to Github. This way if the tests are failing, no code will be pushed to our repository, until we fix our code!

Open package.json and add the pre-push script:

"husky": {
    "hooks": {
      "pre-commit": "npm run lint:fix && npm run lint",
      "pre-push": "npm run test"
    }
  }

Now we can run git add -A and npm run commit and it will run our lint and test tasks!

You can check this finished chapter on github https://github.com/AndreVarandas/mood-sentences/tree/writing-tests

That's all for this part, thanks for reading! In the next part, we will set up our continuous integration (CI) to build our package and publish it into npm!

Writing code

André Varandas — Tue, 18 Aug 2020 09:36:09 +0000

Repository for this part is available on git branch writing-code

AndreVarandas / mood-sentences

✨ Mood sentences

Writing code!

At last, we are going to write some code. Start by creating a src folder at the root of our project. This folder will be home for all our code. We may add subfolders to it, but all code goes into src!

mkdir src

After that, let's add our main JavaScript file, let's be bold and call it index.js

touch src/index.js

We will also need another file - the JSON file that will contain our mood sentences.

touch src/mood-sentences.json

Add the file contents:

{
    "anger": [
        "I'm furious",
        "That really drives me up the wall",
        "I go bananas",
        "I want to tear my hair out",
        "My blood is boiling"
    ],
    "excitement": [
        "I can't believe it",
        "Im really stoked",
        "That's fantastic",
        "How awesome",
        "I'm very excited"
    ],
    "boredom": [
        "It does nothing for me",
        "I can't say I find it interesting",
        "I can’t see what all the fuss is about",
        "It bores me to tears",
        "What a bore"
    ],
    "happiness": [
        "I'm very pleased",
        "I'm over the moon",
        "I'm on cloud nine",
        "I'm pleased as a punch",
        "I'm on top of the world"
    ]
}

Please ignore the quality of the sentences. Let's use it as it is, for now, we can always improve them later.

Now we are ready to start adding some code to our index.js.

We want to start by importing the JSON file.

const moods = require('./mood-sentences.json')

Then we want to create a method that will receive a string for the mood and return a random sentence for it.

const moods = require('./mood-sentences.json')

const getRandom = (mood) => {
  if (mood in moods) {
    return getRandomItemFromArray(moods[mood])
  }

  throw new Error(`Requested mood "${mood}" is not in the moods list!`)
}

💡 We should care about error handling, and assume that things can go wrong.

Notice that we call getRandomItemFromArray, let's define that function now:

const moods = require('./mood-sentences.json')

const getRandomItemFromArray = (array) => array[Math.floor(Math.random() * array.length)]

const getRandom = (mood) => {
  if (mood in moods) {
    return getRandomItemFromArray(moods[mood])
  }

  throw new Error(`Requested mood "${mood}" is not in the moods list!`)
}

To make the life of the user easier, we will add a simple "enum" and call it just list, so even if the users don't know all the available moods, we provide them.

const moods = require('./mood-sentences.json')

const getRandomItemFromArray = (array) => array[Math.floor(Math.random() * array.length)]

const getRandom = (mood) => {
  if (mood in moods) {
    return getRandomItemFromArray(moods[mood])
  }

  throw new Error(`Requested mood "${mood}" is not in the moods list!`)
}

const list = {
  ANGER: 'anger',
  BOREDOM: 'boredom',
  EXCITEMENT: 'excitement',
  HAPPINESS: 'happiness'
}

We can always add more moods, we just need to make sure that the object values exist in the JSON file.

That's all the code we need for our simple package. We just need to actually export them, so our users can use it properly.

const moods = require('./mood-sentences.json')

const getRandomItemFromArray = (array) => array[Math.floor(Math.random() * array.length)]

const getRandom = (mood) => {
  if (mood in moods) {
    return getRandomItemFromArray(moods[mood])
  }

  throw new Error(`Requested mood "${mood}" is not in the moods list!`)
}

const list = {
  ANGER: 'anger',
  BOREDOM: 'boredom',
  EXCITEMENT: 'excitement',
  HAPPINESS: 'happiness'
}

module.exports = {
  all: moods,
  anger: moods.anger,
  boredom: moods.boredom,
  excitement: moods.excitement,
  happiness: moods.happiness,
  getRandom,
  list
}

Our simple package is ready! It's now probably a good idea to add some comments and jsdoc strings to the file, so the users can get code hints when using our package.

Here's the full file, commented out:

// Import our moods list
const moods = require('./mood-sentences.json')

/**
 * From the received array, returns a random element.
 *
 * @param {[]} array of items to choose from.
 *
 * @returns A random element from the array.
 */
const getRandomItemFromArray = (array) => array[Math.floor(Math.random() * array.length)]

/**
 * Enum of available moods.
 */
const list = {
  ANGER: 'anger',
  BOREDOM: 'boredom',
  EXCITEMENT: 'excitement',
  HAPPINESS: 'happiness'
}

/**
 * Gets a random sentence of the received mood.
 *
 * @param {list} mood to use.
 *
 * @throws Will throw if the received mood is not known, undefined or null
 *
 * @returns {string} a random sentence for the chosen mood.
 */
const getRandom = (mood) => {
  if (mood in moods) {
    return getRandomItemFromArray(moods[mood])
  }

  throw new Error(`Requested mood "${mood}" is not in the moods list!`)
}

module.exports = {
  all: moods,
  anger: moods.anger,
  boredom: moods.boredom,
  excitement: moods.excitement,
  happiness: moods.happiness,
  getRandom,
  list
}

You can see all the changes done for this chapter on Github writing-code chapter - https://github.com/AndreVarandas/mood-sentences/tree/writing-code

Thanks for reading. That's all for this chapter, in the next one, we will start adding some tests!

Initial Setup

André Varandas — Tue, 18 Aug 2020 00:09:53 +0000

Repository for this first part is available at branch initial-setup

AndreVarandas / mood-sentences

✨ Mood sentences

First things first

Let's start by creating our git repository. I like to create the repository in Github first. This way, when I run npm init -y a lot of stuff will be populated for me (such as author, description, issues and git links, etc.)

Head to https://github.com/new to create the new repository. Name it something like mood-sentences. The rest is up to you. I usually add node .gitignore and a license file. Here is a screenshot of my configuration:

Yes, the repository is private for now, but we will change that in the future. By the time you read this, it should be already public - this tutorial only covers public packages. 😉

Hit that Create repository green button! Let's clone the project into our machine. git clone https://github.com/YOURUSERNAME/mood-sentences.git

Change directory into mood-sentences and run npm init -y on it. Magically, a package.json file will appear at the root, containing information about our package, such as issues, homepage links, author, etc.

This file will contain all the useful scripts and dependencies for our app. For now, it's just the skeleton, and we have everything ready to start shaping our app!

Let's change the package name, so it is now part of an organization @varandas/mood-sentences. (more on the last chapter)

{
  "name": "@varandas/mood-sentences",
  "version": "1.0.0",
  "description": "✨ Mood sentences",
...rest

This avoids clashing with other existing packages - and I encourage you to add your name as a prefix as well.

If anything goes wrong during the tutorial, check my full package.json file in the https://github.com/AndreVarandas/mood-sentences/tree/initial-setup.

node_modules

When I start a new package I like to add a few things (packages!) right away. As we are including those packages in our project we call those our app dependencies. These are pieces of code that are installed directly into a special folder, that you've probably already seen, called node_modules. This folder contains all of our app dependencies.

When we install a new dependency we can specify if it's a development dependency or a dependency.

We can do that while installing a new dependency with npm install package-name --save-dev for a dev dependency or npm install package-name --save for a dependency.

A devDependency as the name implies is a dependency that we only use for development purposes - and will not be included in our final product. It's good idea to avoid bundling dev dependencies into our final package.

Adding our first dependency

To show this, let's start by adding eslint and a few plugins to keep our code clean of errors. I like to use the standard configuration.

npm install --save-dev eslint eslint-config-standard eslint-plugin-import eslint-plugin-node eslint-plugin-promise eslint-plugin-standard

This "train" of packages, will add a new entry to our package.json file named devDependencies and a new node_modules folder including the eslint and plugins packages.

Now that we have eslint installed we can configure our code editor to format on save using eslint and add new scripts to package.json so that we can use them from the console:

...rest..
"scripts": {
    "test": "echo \"Error: no test specified\" && exit 1",
    "lint": "eslint . --ext .js",
    "lint:fix": "eslint --fix --ext .js ."
  },
...rest...

When you add an entry to the scripts section, you'll be able to run npm run script-name and it will be executed.

Now we can run npm run lint to check for syntax errors and npm run lint:fix to fix them.

Let's add another development dependency that is going to help us writing better commit messages. I usually go with commitizen https://github.com/commitizen/cz-cli - it basically asks us a few questions when we add a new commit. Besides forcing us to write good commit messages it also plays nice with semantic-release package that we are also going to use for managing release versions.

Install with:

npx commitizen init cz-conventional-changelog --save-dev --save-exact

This will also add a few configurations to our package.json between them is a config.commitizen property that is going to be used by the package itself.

The only thing we need now is to add a new commit script to our package.json so it now looks like:

...rest...
"scripts": {
    "commit": "npx git-cz",
    "test": "echo \"Error: no test specified\" && exit 1",
    "lint": "eslint . --ext .js",
    "lint:fix": "eslint --fix --ext .js ."
  },
...rest...

Now whenever commit new changes, we use npm run commit instead of git commit for it to generate beautiful commit messages.

We should also install a testing framework (everybody tests their apps right? 🤓), we are going to use jest:

npm install --save-dev jest

Create a new configuration file for jest named jestconfig.json at the root of the folder with the following contents:

{
  "testRegex": "(/__tests__/.*|(\\.|/)(test|spec))\\.(js?)$",
  "moduleFileExtensions": [
    "js",
    "json",
    "node"
  ],
  "collectCoverage": true
}

This will tell jest where to look for the tests, what file extensions to use, and to collect code coverage.

And update the test script so we can use it later:

...rest...
  "scripts": {
    "commit": "npx git-cz",
    "test": "jest --config jestconfig.json",
    "lint": "eslint . --ext .js",
    "lint:fix": "eslint --fix --ext .js ."
  },
...rest...

As a final step for this initial setup, let's also install another devDependency called husky. Husky will enable us to run npm scripts when certain actions occur, such as when we commit or push code to git.

npm install --save-dev husky

Then update package.json to run some scripts when we commit. Later we will also a pre-push hook to run our tests - I recommend adding this before the last closing bracket:

...rest...
"husky": {
    "hooks": {
      "pre-commit": "npm run lint:fix && npm run lint"
    }
  }
...rest..

Wow, that was a lot of work for just setting up our project. But it will pay out - I promise. This is all the setup I usually do when writing packages.

Lastly, let's commit and push our changes using our new commands:

git add -A
npm run commit

You will now be prompted by commitizen, and you should pick feature and add a small commit message.

After that husky will fix any lint errors and report back if any is left and not auto-fixable 🤓.

Don't forget that you can check this first part on https://github.com/AndreVarandas/mood-sentences/tree/initial-setup

Thanks for reading! We will continue our journey on building our first package in the next chapter, and actually write some code!

Let's build our first JavaScript npm package!

André Varandas — Tue, 18 Aug 2020 00:09:14 +0000

About JavaScript packages

You've probably already used some JavaScript libraries, scripts, blocks of code you found online or you might even already built your own library. The need for a package comes when we want to reuse and share code and functionalities with others.

A package, usually, is just a set of functions and/or variables or full-fledged apps and cli's that are made available for us to build our own.

To make it easier for us, fortunately, nodeJS has multiple systems that allow us to maintain, manage, and share these scripts - so they can be enclosed in a "package". The most common or famous one is NPM (Node Package Manager).

Let's say that you want to share some functionality between multiple projects. For this, we can write the code we need, "package" and push it to npm to distribute it.

The project that we are going to work on might not be of any use right now, but it's a good example of a simple JavaScript package - we want to share some functionality between projects and let NPM manage that for us - so we don't have to copy-paste code everywhere.

About our package - mood-sentences

In this series, we will build a simple package and push it to npm registry. We will cover everything from the very beginning of creating a new git repository to publishing our code to the package manager.

Project idea 💡

Note: To be honest with you, I haven't searched for this package. But it probably already exists. 😏

Imagine that we have a Discord chat bot and we need to send some messages when someone joins the server. We could write an array of sentences like "Welcome to the server John 🎉" and then randomly pick one, or, we could write a JavaScript package that exports multiple sentences for different moods as we need them.

This would enable us to focus on the mood sentences, share them with others, reuse in other projects, and hopefully receive some nice Pull Requests with more sentences and moods. 🤓

We will write some sentences into a JSON file, that reflects multiple moods, starting by adding some sentences that can be used to express:

Anger, excitement, boredom and happiness

Then we will add a few methods to return sentences.

The full project is available on Github, and has multiple branches, each one, corresponds to a chapter of this series.

AndreVarandas / mood-sentences

✨ Mood sentences

Thanks for reading, in the next part we will start adding our own dependencies and preparing everything to work on our package.