We'll review the different ways I know to handle path and current directory in javascript
For each example below we'll assume this folder structure :

```
app
├── main.js
└── lib
 └── script.js
```

<AnchorTitle id="process_and_dirname"> process.cwd() and __dirname </AnchorTitle>

- **process.cwd()**: returns the absolute path to the directory from which the `node` command has been invoked. It is a global property.
- **__dirname** : returns the absolute path to the directory containing the source file that is being executed.


With our structure above, let's assume we have the following code :

```javascript
// main.js
const script = require ('./lib/script.js')
```

```javascript
// script.js
console.log( process.cwd())
console.log(__dirname)
console.log(__dirname===process.cwd())
```

We invoke it from `main.js`

```bash
cd app && node main.js
```

Output:
```javascript
/Users/matt/personal/test-cwd-dirname/app
/Users/matt/personal/test-cwd-dirname/app/lib
false
```

Now let's say we invoke it directly from the `script.js`

```bash
cd app && node lib/script.js
```

Output:
```javascript
/Users/matt/personal/test-cwd-dirname/app/lib
/Users/matt/personal/test-cwd-dirname/app/lib
true
```

&nbsp;

<AnchorTitle id="path_join_and_path_resolve"> path.join and path.resolve </AnchorTitle>

- **path.join** returns a normalized path by merging two paths together. It can return an absolute path, but it doesn't necessarily always do so
- **path.resolve** turns a sequence of paths or path segments into an absolute path. Consuming path from right to left and stopping at the first absolute path found

#### What they have in common :

- they both return a path
- they both take care of normalizing the path. (resolving the ../ for example or dedupping the /)

#### When are they equivalent :

- When you pass them an absolute path as the only argument

```
console.log(path.join('/ssl')); => "/ssl"
console.log(path.resolve('/ssl')); => "/ssl"
```

- When you pass them an absolute path followed by some non-absolute extra path segment :

```
console.log(path.join(__dirname, some, dir)) === console.log(path.resolve(__dirname, some, dir))
```

#### What if you don't provide arguments :

Let's assume we use the same folder structure as above with the following `script.js` file

```
app
├── main.js
└── lib
 └── script.js
```

```javascript
// script.js
console.log(path.join());
console.log(path.resolve());
```

We invoke it from `main.js`

```bash
cd app && node main.js
```

Output:
```javascript
.
/Users/matt/personal/test-cwd-dirname/app
```

Now let's say we invoke it directly from the `script.js`

```bash
cd app && node lib/script.js
```

Output:
```javascript
.
/Users/matt/personal/test-cwd-dirname/app
```

We can see that `path.resolve` when not provided any argument will yield the same result as `process.cwd()`

Hope this helped you clarify the main differences of those nice utilities, as it helped me.

Ressources :

- [https://stackoverflow.com/questions/9874382/whats-the-difference-between-process-cwd-vs-dirname](https://stackoverflow.com/questions/9874382/whats-the-difference-between-process-cwd-vs-dirname)
- [https://stackoverflow.com/questions/39110801/path-join-vs-path-resolve-with-dirname](https://stackoverflow.com/questions/39110801/path-join-vs-path-resolve-with-dirname)
- [https://stackoverflow.com/questions/35048686/whats-the-difference-between-path-resolve-and-path-join](https://stackoverflow.com/questions/35048686/whats-the-difference-between-path-resolve-and-path-join)

There are different ways to play with path in JS, wanted to make a recap / reminder for myself as I was tired of googling it every time

Differences between __dirname, process.cwd, path.join and path.resolve

I've recently set up the whole CI/CD workflow for a project at work, this was the first time I was really diving into CI configuration and automated deployment with this stack. With the combination of the tools below, I feel we have achieved the right mix of confidence / automation for our current needs.

<AnchorTitle id="tools-responsibilities"> Tools and their responsibilities</AnchorTitle>

- **CI** : We use [CircleCI](https://circleci.com/) for running all our tests / linting / type checking for both front end and backend. It also orchestrates backend deployment for Firebase function
- **Vercel** : We use [Vercel](https://vercel.com/) to deploy our front end. It is linked to our github repo to automatically deploy the front-end.
- **Firebase** : We use [Firebase](https://firebase.google.com/) for the backend (serverless functions as well as database and authentication). Generally we'll use one project for development and one project for prod.


<AnchorTitle id="overview"> Overview</AnchorTitle>

<Image
 src="/CI_CD_Firebase_Vercel_overview.jpeg"
 alt="Continuous integration and deployment with Firebase, Vercel and circleCI"
 width={700}
 height={900}
/>


<AnchorTitle id="front-end">Front-End</AnchorTitle>

Our client is basically a [NextJs](https://nextjs.org/) React app. It pairs really well with Vercel since they are the ones behind NextJs, the integration / tooling is really fluid.

To get started you'll need to:
- Have 2 branches on github (usually I go with develop and master)
- [Register your prod and dev domains on Vercel](https://vercel.com/docs/custom-domains#adding-a-domain)
- [Link your 2 domains to the right github branch](https://vercel.com/docs/custom-domains#assigning-a-domain-to-a-git-branch)

This should be enough to get you started and being able to deploy automatically whenever you merge on your configured branch on vercel.

If you need to customize the build-step, whereas it is the command or the output folder, you can follow their [documentation](https://vercel.com/docs/build-step)


**Environment variable**

All your environment variables [can be set up directly on Vercel](https://vercel.com/docs/environment-variables)

If you need to provide different values in your codebase based on the branch you're on (and therefore whether you target your staging or prod domain) you can rely on the [System Env Variables](https://vercel.com/docs/environment-variables#system-environment-variables)

```typescript
export const getEnvVar = (key: string): string => {
 const isProd = process.env.NEXT_PUBLIC_VERCEL_GITHUB_COMMIT_REF === 'master';

 switch (key) {
 case 'NEXT_PUBLIC_FIREBASE_API_KEY':
 return isProd
 ? process.env.NEXT_PUBLIC_PROD_FIREBASE_API_KEY
 : process.env.NEXT_PUBLIC_FIREBASE_API_KEY;
 default:
 throw new Error(`key ${key} is not recognized `);
 }
}
```


**Note on firebase hosting :**
To deploy it we were initially using firebase hosting, but it was rather slow as you need to rely on a serverless function from firebase to serve the server side content.

If you want to use Firebase Hosting you would be limited to a function in `us-central1`. This is a [known limitation](https://stackoverflow.com/questions/65304321/serve-dynamic-content-with-firebase-hosting-functions-in-eu) and for the meantime if you want to serve dynamic content you would have to configure [Google Cloud Run](https://firebase.google.com/docs/hosting/cloud-run) instead

<AnchorTitle id="back-end">Back end - firebase serverless functions</AnchorTitle>

This part is a bit trickier between local and prod setup. There are a few firebase key concepts behind it.

- **Firebase project** : usually you use a firebase project for your prod, and one for your staging. Meaning that you will need to switch between project whenever you want to deploy code on staging or on prod. This will be automated through CI.
- **Service account** : This is one of the way to authenticate yourself as an admin of a firebase project. Your service account can be generated in the firebase console
- **RuntimeConfig :** this is the config you can set up through `firebase CLI` usually to add env variables associated to your firebase project.
- **Firebase CLI :** The command line tool which allow you to perform several tasks on firebase like :
- login into your firebase project.
- adding/selecting the project you're currently working on
- adding env variable to your project
- generate the firebaseToken needed to deploy through the CI

We'll go through each of them in the setup below, don't worry (I'm mostly speaking to myself for the next time I need to configure this 😄)


<AnchorTitle id="common-setup">Setup commmon to both local and staging/prod</AnchorTitle>


**Firebase Project Configuration :**

- You'll therefore first need access to one or two firebase projects. This setup will mostly walkthrough having 2 firebase projects (staging and prod) with each their own authentication and database. Just log on [firebase and follow the steps](https://console.firebase.google.com/)
- Install firebase-cli

```bash
npm install -g firebase-tools
```

- Login through firebase-cli. This allows the next steps

```bash
firebase login
```

- Once you're logged in you'll be able to add different firebase projects to your current configuration by :

```bash
firebase use --add
```

This should result in `.firebaserc` file in your project where you'll have a list of your projects. This is important as we'll rely on those aliases to target the right project to deploy based on the branch later on. Would you have any issue you can refer to [firebase-cli documentation](https://firebase.google.com/docs/cli#install-cli-mac-linux) which rather good.

**Environment variable :**

For your env variables you can add them directly to your firebase project through firebase CLI :

```bash
firebase functions:config:set someservice.id="THE CLIENT ID"
```

You can later on access it through :

```
const functions = require('firebase-functions');
...
const id = functions.config().someservice.id,
```

**Note :**
Those environment variables are stored directly in your project on firebase and as such you don't need them locally. Usually you download them locally to verify a value manually. Might be a good idea to gitignore them, just in case.

**Initialize admin SDK :**

To configure and add your firebase-admin sdk, you'll need to [add a service account](https://firebase.google.com/docs/admin/setup#initialize-sdk).

This will result in a local .json file, that you will place under a specific gitignore folder on your machine.

Firebase then recommends putting the path of the file in an environment variable (previous section) - you can refer to the [firebase docs if needed](https://firebase.google.com/docs/admin/setup#initialize-sdk)

```javascript
import * as admin from 'firebase-admin';
...
const config = functions.config();

const app = admin.initializeApp({
 credential: admin.credential.cert(config.credentials.google_application),
 databaseURL: `https://${config.credentials.project_id}.firebaseio.com`
 });
```

<AnchorTitle id="local-setup">Local Setup</AnchorTitle>

To develop locally, usually I end up using the staging project for database/auth and serverless function. This can be achieved by :

- select your firebase project manually through firebase CLI with `firebase --use XXX`

**Note :**
Pay attention to which project you're currently using, sometimes you want to run a script against prod and you end up using `firebase --use master` which will be the selected project untill you reselect staging / your test env

We want to avoid deploying the serverless functions manually at this stage and want to pass this responsibility to the CI


<AnchorTitle id="ci-setup">CI Setup</AnchorTitle>

The CI will be responsible for deploying our functions to firebase.

There is obviously some constraints :

- you don't want to expose your serviceAccount in your repo
- you need to switch the project used to deploy based on the branch

To achieve those goals we have to configure a few things :

- take the path to where your service account is supposed to be stored and save it as an env variable on CircleCI.
- take your local serviceAccount and [encode it to base64](https://support.circleci.com/hc/en-us/articles/360003540393-How-to-insert-files-as-environment-variables-with-Base64) to save it as an env variable on circleCI. This allows CircleCI to store complex structure as a string.
- a good practice is to add `BASE_64` at the end of your variable name. Usually I end up with 2 var in circleCI, something like : `FUNCTION_PROD_SERVICE_ACCOUNT_BASE64` and `FUNCTION_STAGING_SERVICE_ACCOUNT_BASE64`
- take the serviceAccount from circleCI and decode/copy it through the CI to your build folder :
-

```bash
command: echo << parameters.key_env_name >> | base64 -di > ./keys/<< parameters.key_path >>
```

- Now your code should be ready to be deployed, but you still need to make sure you have the token to allow your CI to handle the deployment. This can be done with [the firebase token.](https://firebase.google.com/docs/cli) This is done only once - you don't need to do it each time you switch the project you're using.
- From there you should be able to deploy your serverless functions based on your branch like so :

```bash
command: ./node_modules/.bin/firebase deploy --token "$FIREBASE_TOKEN" -P << parameters.environment >> --only functions:hubspot,functions:users
```

This can only be triggered based on the branch you're running the merge against. Like so

```yaml
- functions_deploy:
 requires:
 - functions-build
 environment: staging
 key_path: $STAGING_SERVICE_ACCOUNT_PATH
 key_env_name: $FUNCTION_STAGING_SERVICE_ACCOUNT_BASE64
 filters:
 branches:
 only: develop

- functions_deploy:
 requires:
 - functions-build
 environment: prod
 key_path: $PROD_SERVICE_ACCOUNT_PATH
 key_env_name: $FUNCTION_PROD_SERVICE_ACCOUNT_BASE64
 filters:
 branches:
 only: master
```

```yaml
functions_deploy:
 executor: node
 parameters:
 environment:
 type: string
 key_path:
 type: string
 key_env_name:
 type: string
 working_directory: ~/project/app/functions
 steps:
 - checkout:
 path: ~/project
 - attach_workspace:
 at: ~/project
 - run:
 name: add service account
 command: echo << parameters.key_env_name >> | base64 -di > ./keys/<< parameters.key_path >>
 - run:
 name: Firebase Deploy
 command: ./node_modules/.bin/firebase deploy --token "$FIREBASE_TOKEN" -P << parameters.environment >> --only functions:hubspot,functions:users

```

That should be it and you should now have a fully automated deployment with Vercel and Firebase for both the front end and backend on your staging and prod environment.

I hope this has been helpful to you and that you learned a few things along the way, I surely did !

A production workflow I use when working on serverless project, the combination of circleCI, Vercel and Firebase are a great way to automate and build confidence into your daily deployment routine

Continuous integration and deployment workflow with Vercel, Firebase and CircleCI

I switched career at 33 through a bootcamp. A lot of us do it at various ages, some younger, some later on. I globally really enjoyed the ride and learning experience.

During the bootcamp we were exposed to the concept of [growth vs fixed mindset](https://fs.blog/2015/03/carol-dweck-mindset/), at this stage the concept seemed to click - it was feeling comfortable, I was confident in my ability to learn and proud of my capacity to pivot.

And then it happened after the first few months at my first dev job - I realised the hardest thing for me was to embrace **being a beginner once again**.

I don't consider myself having a big ego (but who does ? 🤔 ), nevertheless it became a hindrance after a few months when I was often comparing myself to other devs, most of them senior, all of them having a more valuable contribution to the company than me.

I believe this feeling came from 2 main dimensions :

- my own mental capacity to cope with the career switch / impostor syndrome
- the job environment

<AnchorTitle id="impostor-syndrome">Impostor Syndrome / Self Doubts</AnchorTitle>

There is a lot of [good advices](https://www.codingdojo.com/blog/programmer-imposter-syndrome) on how to cope with impostor syndrome over the internet.
Impostor syndrome is mostly self doubts and as such can be difficult to handle.
I don't have much more advices to share on the way to handle it from within yourself, but rather I want to focus on the second point where I might have a bit more concrete advices : **picking a healthy job environment.**

<AnchorTitle id="job-environment">Job Environment</AnchorTitle>

During my first job hunt as a dev I tried to get the job with the best learning environment.

Naively I thought that a company with a lot of senior dev + "standard best practices" would be the best to learn from.

I was wrong.

I ended up in a company which had a lot of senior devs, some of them being really impressive in their technical knowledge and problem solving skills. I still learned a lot from them, but while months were going on I began to realize that the place was **not feeling safe**.

We're not talking about physical integrity but rather about an environment where it feels safe to learn / grow / fail. There is [an interesting study on google teams](https://rework.withgoogle.com/blog/five-keys-to-a-successful-google-team/) or the well known book : [5 dysfunctions of a team](https://www.goodreads.com/book/show/21343.The_Five_Dysfunctions_of_a_Team) which explains how this can be impacting.

It's kind of difficult when you begin your dev career, to differentiate the impostor syndrome and its consequences (lack of confidence etc) versus a more rooted issue from the environment itself.

The question always comes up as a personal issue till you're able to articulate it with other colleagues and you realise that the feelings are shared.

Concretely here are some symptoms we were experiencing :

- Lack of encouragement
- Code review feedback lacked empathy
- We didn't feel our work was valuable to the company
- Subtle but constant pressure about our capacity to match senior output

Those are mostly perception related things and it could vary from one individual to another - but when they stack, they definitely create a non productive environment for those who are not confident enough by themselves.

It often leads you to doubt about your skills, your learning abilities etc. When you switch career and don't have much experience to compare with, you can even doubt about your initial move of becoming a developer.
This level of self-doubts affects obviously your personal life.

This should be a red flag about the company and the environment, if you see it not only as a punctual feeling/experience you have, but rather a trend/direction.

With some perspective now I feel there were several root causes :

- **company capacity to make junior dev grow**
- **cultural misfit**

My first company, and I cannot blame them for that, was not used to recruit junior dev. They had a strong stable and trusted team for a long-lived product for which they were only recruiting seniors. It's difficult to be good at something you don't practice.

Cultural fit is to me how you share values and you can relate to your colleagues. When difficult times arise (as it will), you will rely on this fundamental aspect to be able to communicate/articulate the issue. As those topics are already difficult to share, when you feel out of place, it will be all the more difficult to share and address them.

In all honesty when we talk with my ex colleagues, we're still grateful for the experience as we learned a lot by just being in contact of great knowledgeable developers.

But having now experienced others working environments - I think as a first job, the best learning environment is a place where it can feel safe to grow. I don't say it has to be all comfortable and indulging (quite the opposite in fact) but rather an environment where you feel you can tackle challenge and you can go out of your comfort zone while being supported.

That's why I think it's an important skill to be able to assess those aspects early on in the recruiting process.

<AnchorTitle id="first-job">Get a first job where you can build confidence in your skill</AnchorTitle>

I understand that the situation is not identical for all students / junior dev and that we cannot always "choose" our first job - that being said, knowing how to assess your future job environment is a skill in itself, and that will be useful for all your other jobs.

**Company capacity to make junior dev grow :**

In my opinion, you can have a good idea of the company capacity to support the growth of junior dev by looking at :

- onboarding process
- junior dev turnover / frequency of hiring junior
- collaboration process

Most of those aspects can be assessed fairly well during the recruiting process, by asking questions such as :

- What is the process to onboard new team members ?
- What are the expectations for a junior dev at 3 months, 6 months, a year ?
- Do you often onboard junior dev
- Do you have a Career Framework ?
- What are the values important to your team to ensure a good collaboration ?
- What space/trust/ownership has a developer to explore some feature/aspect/optimization ?

Special mention about the Career Framework - This is usually something which comes up when you have more than XX devs - therefore the lack of it might not be a red flag in itself.

**Cultural fit :**

This can be trickier I feel to assess as there is a lot of "marketing" these days around it with culture books and shiny endeavour which do not always guarantee a concrete translation in a day to day work.

I think this is best assessed by meeting team members and asking questions about their own journey / struggles and how you can relate to those.

Meeting people that went through the same path/steps as you do will prove useful and will facilitate meaningful support when needed.


<AnchorTitle id="conclusion">Conclusion</AnchorTitle>

As previously mentioned, and I want to reiterate, I'm still grateful for all my previous experiences and all the learnings that came out of it (technical or non technical related).

That being said, we as fresh bootcamp student (or fresh graduates in general) tend to rush to accept the first offer. Despite the urge and pressure of doing that, we should be able to gauge a company environment in term of learning expectations not only through the tech stack but also through team dynamics, process and values.

Genuinely foster a learning environment for all is a difficult task, and we also have a responsibility as junior dev and future seniors to be a part of improving/creating it.

Some resources to go beyond this post and inspire a broader perspective on the question

- 🎥 [a talk of Sarah May about power dynamic in agile teams](https://www.youtube.com/watch?v=YL-6RCTywbc)
- 📖 [swyx excellent book on the coding career](https://www.learninpublic.org/#learn-more). There are specific chapters around the career guides section.

As a developer it is vital that we learn and grow through our daily job. Finding/assessing a healthy environment might be trickier than it appears, here are some humble advices from my own short experience.

First Job as a junior dev - find a place where you can build confidence


When I was preparing for my bootcamp a year and half ago I was trying to figure out the best way to learn. (still figuring...). What I learnt finally over the last year, is not what is the best way to learn Javascript, but rather what doesn't work for me.

So instead of recommending you what to do, I'm going to focus on what failed for me.

- Resources overload
- Not knowing how to learn
- Too many topics at the same time (following my first job as a dev I had to learn Redux, c#, SQL, RxJs. Mixing all those together was a bad idea)
- Not Planning and Chunking
- Too much screen time
- Comparing to other too much
- Not being indulgent with yourself

### Resources overload

What should I learn and what are the best resources to learn out there ? Those were the first questions I asked. And Google served me well there,
with a lot of good resources and opinionated learning roadmap.

I was literally trying to read too much. Anytime I was seeing a good article, or a link recommended by someone it was ending on a todo list somewhere.

If you've been there, you might recognize you in the situation below :

> _- List of paid course on Udemy that you haven't even started (I'm talking about those 2yrs old course which are now outdated)_

> _- Trello backlog full of articles links that never shortens._

> _- Medium bookmark section that is not even scrollable anymore._

Bookmarking good content in itself is not a bad habit, but I felt like I would never catch up on my plan, which is kind of depressing.
I'm still kind of there, but I decided to not bookmark medium articles neither buying udemy course anymore, unless I'm doing them right away.

### Not knowing how to learn

Before switching career, I did some Coursera/PMP certifications, but there were short bursts, and the main objective was to get the certification - I was not paying attention on how I achieved this goal.
When I entered the more technical field of web dev, it felt like a new world to me, where I would need to learn differently.

At first my learning practice consisted mainly in reading article on a topic (according my never ending trello backlog), and then try to apply the learning in a side project.
This was at first intuitive to me, but while I was learning Redux, it was dissatisfying.

- First because, there were always some more resources or links to go through. I kinda felt depressed to find **Mark Erikson** [awesome list or resources](https://github.com/markerikson/react-redux-links). as I felt like I should go through it .
- Secondly because, I was trying to learn everything upfront at the same time. (redux, redux thunk, redux-connect, rxJs)
- Finally, because after a while I thought I was forgetting my previous learning.

After I took a step back - I decided to make some corrections in my approach :

- Focus my learning on specific platforms/authors.
- Chunking and Planning
- Learning by repetition

I have a few authors who are my go-to mentors because I like the way they teach.
When I can't find what I'm looking through them, then I go in the wild - not before.

Chunking and planning is discussed just below.

As regards for repetition, I remember when I was at school preparing for some exams, I created those flashCard - they were a pain to make,
but by the process of making them and having them around allowed me to get the best marks I ever got and still remember them. Fast-forward 15 years later, I thought I could use some of this wisdom,
by creating Cards on different learning topics. This works pretty well at least for high-lvl concepts, for example when you approach a new topic.

### Not Planning and Chunking

My main objective for 2018 was to learn Redux, GraphQL and Advanced React Internals while working on a side project. I haven't touched GraphQL, very few of React internals, and my side project has seen  a few commits but way less than I would have expected.

The culprit ? The preceding points for sure, but also the way I was planning my learning journey.
Learning Redux is a big bold statement, but it didn't serve me well as I didn't feel I was making progress towards the overall goal.

I should have before chunked Redux in some smaller part would have been preferable and more digest to learn.

For 2019, I have some similar main goals (JS fundamentals - again..., GraphQL, Node) but in a way more specific manner. I try to chunk those big topic in weekly learning chunks, that I can apply in my side project.

### Too much screen Time

I try to pay attention to my screen time - coming from project management world where meetings were the norm (for bad or for good),
switching to dev was a huge increase into my computer hours. I feel it painful sometimes to go back at home to practice/learn to code in front of my computer.

That's where I like flashcards and books. Not all resources are equals, and some books are more helpful to sleep than to learn.
Adjust accordingly to your energy level.

### Comparing to other too much

We're getting personal here, but during the bootcamp and through my first job year, I realized that I compared myself to my co-workers. A lot.
Doing so prevented me to learn from my environment as much as I could as I felt diminished when I wasn't performing enough.

It takes a lot of energy to manage this kind of emotion. This is a net loss that you cannot put in good use to learn from your coworkers or peers.

I don't have the answer yet to this, but paying attention to this emotion and pattern allow me to avoid getting caught in too much.
Knowing that my interest lies in welcoming learning opportunities rather than feeling diminished by them helps.

### Not being indulgent/empathic with yourself

This is kind of linked to the previous point. I have moment in my journey where I mostly focus on what I'm lacking or not doing well enough.

When this happens I try to take a step back.

Learning to Code is hard.

Switching Career is hard.

It's a long journey, and I should already be proud of where I am. So should you.


Javascript is hard to learn. It's hard to know what to learn with the resources overload

How to not learn Javascript


I always look up on stackOverflow for this one. Most of the company I've worked in use github or some similar software where the remote feature branch is automatically deleted when you merge your PR.

This is great for housekeeping and keeping your repo clean, but it doesn't happen magically on your computer. There you have 2 choices :

- you delete your branch manually whenever a PR is merged. It's the cleanest way, but you need some discipline !
- you have a script which goes through your current branch and delete them base on criteria (which can be precarious sometimes, relying on a commit msg for example)

I prefer the second option as I can automate the process through this script:

```
git fetch -p && for branch in $(git branch -vv | grep ': gone]' | awk '{print $1}'); do git branch -D $branch; done
```

several steps here :

```
git fetch -p
```
remove all the remote reference that no longer exists (making sure your local branch knows that their remote counterpart and reference are gone)


```
&& for branch in $(git branch -vv | grep ': gone]' | awk '{print $1}');
```
The `-vv` allow to list the branch with extra information (stand for verbose) - displaying if the branch is `gone`.
We then rely on grep to get to match to select the branch on `: gone]` and using awk to pass it to the next part of the script

Side Note : this can be fragile, as if the last commit of the branch includes `: gone]` it will delete it.

```
do git branch -D $branch; done
```
delete the corresponding branch


Credit to  [stackoverFlow thread](https://stackoverflow.com/a/33548037/6432753)

Blog Posts

Differences between __dirname, process.cwd, path.join and path.resolve

Continuous integration and deployment workflow with Vercel, Firebase and CircleCI

First Job as a junior dev - find a place where you can build confidence

How to not learn Javascript

Books

Snippets

Delete local git branches when remote branch has been removed