Listing all the possible values in Typescript ain't as easy as it seems!

Today I have spent quite a few hours trying to contribute a P.R. to a project I really like, and often use in my day-to-day work, the excellent [`class-validator`](https://github.com/typestack/class-validator).
The problem I was trying to solve consisted in listing the possible values for a given enum, in order to let `class-validator` print them in its enum-related error messages.

The main problem is that enums get transpiled di

When values are not specified, an incremental integer is assigned to each key, so the transpiled JS looks like the following:
```js
// Before
enum Steak {
    Medium,
    Rare,
    WellDone
}

// After
var Steak;
(function (Steak) {
    Steak[Steak["Medium"] = 0] = "Medium";
    Steak[Steak["Rare"] = 1] = "Rare";
    Steak[Steak["WellDone"] = 2] = "WellDone";
})(Steak || (Steak = {}));
```

When an inteer number is assigned as the value, it is simply assigned instead of the deafult incremental integer in the example before.

When a string value is assigned, though, the transpiled JS code looks a bit different:
```js
// Before
enum Steak {
    Medium = "MEDIUM",
    Rare = "RARE",
    WellDone "WELL_DONE"
}

// After
var Steak;
(function (Steak) {
    Steak["Medium"] = "MEDIUM";
    Steak["Rare"] = "RARE";
    Steak["WellDone"] = "WELL_DONE";
})(Steak || (Steak = {}));
```

These transpilation differences lead to obvious inconsistencies when attempting to retrieve an `enum`'s list of possible values when using the common `Object.values()`, `Object.keys()` and `Object.entries()` methods. By fiddling with an heterogeneous `enum` like the following:
```js
enum TestEnum {
	a = 'aA',
	b = 'bB',
	c = 1,
	d = 2,
	e = '01'	
}
```


The following conclusions can be drawn:
- `Object.values()` returns an array containing all the possible values for the given enum AND the keys for the properties which have integer numbers as values (`[ 'c', 'd', 'aA', 'bB', 1, 2, '01' ]`)
- `Object.keys()` returns an array containing all the enum's keys plus all of the integer values defined (`[ '1', '2', 'a', 'b', 'c', 'd', 'e' ]`) 
- `Object.entries()` returns an array of [key, value] arrays, plus N [value, key] entries for N of the enum's properties which have integer numbers as values (`[ [ '1', 'c' ],
     [ '2', 'd' ],
     [ 'a', 'aA' ],
     [ 'b', 'bB' ],
     [ 'c', 1 ],
     [ 'd', 2 ],
     [ 'e', '01' ] ]`)  

  
So, finally, the solution I came up with is:
```js
Object.entries(TestEnum).filter(entry => !parseInt(entry[0])).map(entry => entry[1])
```

Which starts from `Object.keys()`'s results, filtering out all the redundant [value, key] entries.

Listing all the possible values for an enum in Typescript

A nice and clean setup to manage authenticating with different accounts on a variety of different project repositories hosted on cloud services such as GitHub, GitLab, BitBucket, etc..

In this post I'm gonna quickly go over a nice and clean setup I use to manage authenticating with different accounts on a variety of different project repositories hosted on cloud services such as GitHub, GitLab, BitBucket, etc..


### PREPARATION

As a first step, we want to make sure that **all** of our accounts use SSH keys to authenticate connections between our machines and the cloud providers. Nowadays the process doesn't require much fiddling, and can be simply done using our providers' web UIs. I won't go over this part because the specific way to set this up would be vendor-specific, and I don't consider this step to be complicated enough to require any explanation.
\
Let's suppose that at this point we own two different GitLab accounts, each bound to a dedicated SSH key stored on our machine:
```sh
user: first
email: first@myemail.com
private key: ~/.ssh/first/id_rsa
public key: ~/.ssh/first/id_rsa.pub
repository name: first-project

user: second
email: second@myemail.com
private key: ~/.ssh/second/id_rsa
public key: ~/.ssh/second/id_rsa.pub
repository name: second-project
```

### Configuring SSH
If not present, a SSH configuration file needs to be created:
```sh
cd ~/.ssh/
touch config
```

We are going to use said file to tell our machine to use different credentials depending on the host we're trying to connect it to. 

This could lead us to a question: 
> We just assumed both our accounts are gitlab.com accounts. How do we use different credentials if the host is the same?

The answer is straightforward:
ssh can be configured by using host alias names, which will basically allow us to treat the same underlying hostname as two different hosts, while still resolving the correct hostname. 
Let's see how to take advantage of this feature
```sh
# Gitlab.com - "first" account
Host gitlab.com_first   # <-- this could be any alias     
HostName gitlab.com     
User git    
Preferredauthentications publickey    
IdentitiesOnly yes    
IdentityFile ~/.ssh/first/id_rsa

# Gitlab.com - "second" account
Host gitlab.com_second  # <-- this could be any alias     
HostName gitlab.com    
User git    
Preferredauthentications publickey    
IdentitiesOnly yes    IdentityFile ~/.ssh/second/id_rsa
```

### Configuring Git
Our job is pretty simple now: we need to let git use our alias hostnames in order to provide the correct SSH credentials when trying to authenticate  (using only our "first" account for brevity):
```sh
# If the remote repo is still not cloned locally
# we just need to provide our alias hostname
# when cloning
git clone git@gitlab.com_first:first/first-project.git

# If the remote repo is already cloned locally
# we need to update the remote's hostname. Here# we're assuming "origin" its name.git remote remove origin
git remote add origin 
git@gitlab.com_first:first/first-project.git
```

----

## DONE
We're done with our configuration, now the correct credentials will be used when connecting to each remote.

Handling multiple Git credentials the easy way

A simple guide to get up and running with the NextJS + TypeScript + TailwindCSS + Storybook combination.

Following is a simple guide to get up and running with the NextJS + TypeScript + TailwindCSS + Storybook combination, a task which took me a lot more time than I originally estimated, due to the unexpected lack of specific guides on how to deal with this particular scenario plus the sparse nature of the information I had to look up to set everything up as desired.

### NEXTJS SETUP

`yarn create next-app`

That's it. Done. A fully-functional NextJS app will be created using the official starter kit.

---
### TAILWINDCSS SETUP

1. `yarn add -D tailwindcss postcss-preset-env` to install the TailwindCSS library and some useful PostCSS polyfills
2. `npx tailwind init` to generate a `tailwind.config.js` file.
3. Edit the TailwindCSS configuration file we just created to enable and configure the built-in CSS purging process. (Notice how I'm using the ".tsx'" extension here, since I already know I'm going to use TypeScript for this project)
```js
module.exports = {
  purge: ['./components/**/*.tsx', './pages/**/*.tsx'],
  theme: {
    extend: {},
  },
  variants: {},
  plugins: [],
}
```
4. Create `postcss.config.js` to configure PostCSS in a minimal way, like the following
```js
module.exports = {
  plugins: [
    "tailwindcss", 
    "postcss-preset-env"
  ]
};
```
5. Create `/styles/index.css` and populate it using the `postcss-import`-friendly `@import` directives (instead of using `@tailwind`)
```css
@import "tailwindcss/base";
@import "tailwindcss/components";
@import "tailwindcss/utilities";
```
---
### TYPESCRIPT SETUP

1. `yarn add --dev typescript @types/react @types/node`
2. `touch tsconfig.json`
3. `yarn next` to start NextJS, which will automagically recognize our newly created `tsconfig.json` and inject a valid configuration json into it
4. Create a `/pages/_app.tsx` file
```jsx
import React from "react";
import "../styles/index.css"; // <- applied everywhere in the NextJS application scope

const MyApp = ({ Component, pageProps }) => {
  return <Component {...pageProps} />;
};

export default MyApp;
```
---
### STORYBOOK SETUP

1. `yarn add @storybook/react babel-loader @babel/core awesome-typescript-loader react-docgen-typescript-loader -D`
2. `mkdir .storybook`
3. `cp ./tsconfig.json ./.storybook/`
4. Edit `/.storybook/tsconfig.json` to suit your Storybook-TypeScript integration
```json
{
  "compilerOptions": {
    "target": "es5",
    "lib": ["dom", "dom.iterable", "esnext"],
    "allowJs": true,
    "skipLibCheck": true,
    "strict": false,
    "forceConsistentCasingInFileNames": true,
    "noEmit": true,
    "esModuleInterop": true,
    "module": "esnext",
    "moduleResolution": "node",
    "resolveJsonModule": true,
    "isolatedModules": true,
    "jsx": "react"            // <- important!
  },
  "exclude": ["node_modules"],
  "include": [                // <- important!
    "../types.d.ts",
      "../next-env.d.ts",
      "../**/*.stories.ts",
      "../**/*.stories.tsx"
    ]
  }
```

6. Create `/.storybook/main.js` and feel free to copy the following configuration
```js
const path = require("path");

module.exports = {
  stories: ["../components/**/**/*.stories.tsx"],
  webpackFinal: async (config) => {
    config.module.rules.push({
      test: /\.(ts|tsx)$/,
      use: [
        {
          loader: require.resolve("awesome-typescript-loader"),
          options: {
            configFileName: path.resolve(__dirname, "./tsconfig.json"),
          },
        },
        /* 
          ** OPTIONAL ** 
    						 
          Basically a webpack loader  used to 				 
          generate docgen information from TypeScript React components. 
The primary use case is to get the prop types 
table populated in the Storybook Info Addon.
    	*/
    	{
          loader: require.resolve("react-docgen-typescript-loader"),
          options: {
            tsconfigPath: path.resolve(__dirname, "./tsconfig.json"),
          },
        },
      ],
    });

    config.resolve.extensions.push(".ts", ".tsx");

    return config;
  },
};
```

7. create `/.storybook/preview.js` and use it to import our stylesheet as follows
```js
// The preview application is essentially just your stories with 
// a framework-agnostic 'router'. 
// It renders whichever story the manager application tells it to render.
// In this case we just use it to import the stylesheet and inject it 
// in the context of our stories

import "../styles/index.css";
```

8. Update `postcss.config.js` to use an object-based format. This is super important in order to solve any issues Storybook's webpack process may encounter while resolving the dependencies!
```js
module.exports = {
  plugins: {
    tailwindcss: {}, 
    "postcss-preset-env": {}
  }
};
```
---
# DONE

Now you will be able to create your component stories in your own component's folders (ex.: `/components/button/1-button.stories.tsx`) using this powerful toolset.


> P.S.: If you wish to organize your Storybook stories using a different folder structure, you'll need to do no more than editing the `stories` property inside the exported configuration in `/.storybook/main.js` using your desired glob patterns 