In this post I'll show you how you can configure SSH keys for your custom Bitbucket Pipe. This requires a tiny bit of setup, as there is no `~/.ssh` directory on the docker container. This makes using SSH a little more tricky, especially when you're using tools like git or other deployment tools that hide the actual SSH configuration.

Quick rant: who the heck named custom pipeline tasks "pipes". It's pretty much impossible to Google! I just get pipeline results.

In your shell script you'll just need to add the following:

```bash
mkdir -p ~/.ssh
cp /opt/atlassian/pipelines/agent/ssh/id_rsa_tmp ~/.ssh/id_rsa
cp /opt/atlassian/pipelines/agent/ssh/known_hosts ~/.ssh/known_hosts
chmod -R go-rwx ~/.ssh/
```

It's important to copy the `id_rsa_tmp` AND `known_hosts`. Without the known hosts file you'll be unable to connect to remote origins. The `id_rsa_tmp` represents the custom private SSH key that is added into bitbucket pipelines when you follow their guide here: https://support.atlassian.com/bitbucket-cloud/docs/variables-and-secrets/#Use-SSH-keys-in-Bitbucket-Pipelines

Make sure ssh is installed on your docker image of course too!

Setting up SSH on custom Bitbucket Pipes

This weekend I created a [Terraform provider for BigCommerce](https://registry.terraform.io/providers/ashsmith/bigcommerce/latest/docs). The reason for doing is so that you can declaritively define certain aspects of BigCommerce configuration in code. At the moment the provider only supports managing webhooks.

It looks like this:

```
terraform {
  required_providers {
    bigcommerce = {
      source = "ashsmith/bigcommerce"
      version = "0.0.4"
    }
  }
}

provider "bigcommerce" {
 client_id    = "your_stores_client_id" # env var: BIGCOMMERCE_CLIENT_ID
 access_token = "your_stores_access_token" # env var: BIGCOMMERCE_CLIENT_ID
 store_hash   = "your_store_hash" # env var: BIGCOMMERCE_STORE_HASH
}

resource "bigcommerce_webhook" "orders_webhooks" {
  # What scope of events are you listening for.
  scope = "store/order/*" # listens to all order events.

  # Where the webhook event payload will be sent:
  destination = "https://api.myawesomeapi.com/webhooks"

  is_active = true
}
```

Why define webhooks as terraform resources?

This allows us to declaratively define what events are are being consumed, which makes it easy for us to reason our applications infrastructure and it's dependencies. Additionally this terraform code can be applied to multiple environments so that we can ensure they are setup exactly the same.

We can take this a step further when combined with other terraform resources. For example, we can define the `destination` of our webhook to map directly to a HTTP-triggered GCP Cloud Function that will consume the webhook events:

```terraform
# (I have omitted other GCP resources here for brevity)
# Full example of GCP Cloud Function: 
# https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/cloudfunctions_function#example-usage---public-function
resource "google_cloudfunctions_function" "function" {
  name        = "function-test"
  description = "My function"
  runtime     = "nodejs10"

  available_memory_mb   = 128
  source_archive_bucket = google_storage_bucket.bucket.name
  source_archive_object = google_storage_bucket_object.archive.name
  trigger_http          = true
  entry_point           = "testing"
}

resource "bigcommerce_webhook" "orders_webhooks" {
  scope       = "store/order/*"
  destination = google_cloudfunctions_function.function.https_trigger_url
  is_active   = true
}
```

Just like that we'll have all order events sent to a newly provisioned Cloud Function. This is repeatable, and as mentioned before can be applied to multiple environment to ensure consistency in our configuration.

The source code is available on Github:

- https://github.com/ashsmith/terraform-provider-bigcommerce/
- https://github.com/ashsmith/bigcommerce-api-go/

And the Terraform provider is available in the registry here: 

- https://registry.terraform.io/providers/ashsmith/bigcommerce/latest

Terraform provider for BigCommerce

Today I created a small CLI utility called `ssl-gen`. When developing sites or APIs locally, having a trusted SSL certificate locally is always difficult. I can never remember all the parameters, and usually write some horrid bash script. To solve this problem I've created `ssl-gen`. It will generate your certificate and add it to Keychain so that it is registered as a trusted certificate (getting around those annoying invalid cert errors in your browser!).

You can view it on GitHub here: https://github.com/ashsmith/ssl-gen

Installation is with Homebrew:

```bash
brew tap ashsmith/ssl-gen
brew install ssl-gen
```

Then, to use it you provide your desired certificate name followed by the domains you wish to be on the certificate. The first domain will be the used as the common name.

```
# ssl-gen new [cert-name] [domains...]
ssl-gen new ashs-awesome-cert ashsmith.test www.ashsmith.test someothersite.test
```

This will generate `ashs-awesome-cert.crt` and `ashs-awesome-cert.key`. These can be used on your webserver such as nginx or apache to serve your local development site on HTTPS.

`ssl-gen new` also accepts `-o` / `--output` which allows you to specify where the certificate will be saved:

```bash
ssl-gen new ashs-cert ashsmith.test -o ~/.certs
```

Now your certificate will be saved to: `~/.certs/ashs-cert.crt`.

Happy hacking.

Introducing ssl-gen a CLI utility for generating self-signed certificates for macOS

Typescript can be really powerful way of enhancing your react components to ensure the correct props are provided with expected values. Sometimes however you may want some props to required based on what other props have been provided!

Let's dive into an example:

```jsx
const Image = ({ src, width, height, layout, ...rest }) => (
  <img
    src={src}
    width={width}
    height={height}
    className={`layout-${layout}`}
    {...rest}
  />
);
```

Now, our `layout` prop here might only be able to accept certain values. For example: `responsive` or `fill`. So let's convert this example into Typescript:

```tsx
import React, { FC } from 'react';

type Layout = 'responsive' | 'fill';

type ImageProps = Omit<JSX.IntrinsicElements['img'], 'src' | 'width' | 'height'> & {
  src: string;
  width: string | number;
  height: string | number;
  layout: Layout;
};

const Image: FC<ImageProps> = ({
  src, width, height, layout, ...rest
}) => (
  <img
    src={src}
    width={width}
    height={height}
    className={`layout-${layout}`}
    {...rest}
  />
);

export default Image;
```

So now we have correct typed the correct values, what if we wanted to enforce a rule that when `layout="fill"` is provided you are NOT allowed to define the `width` or `height` props. But when `layout="responsive"` is provided you MUST set them.

Well, to do that we can change our `ImageProps` type to support exactly this.

```ts
type ImageProps = Omit<JSX.IntrinsicElements['img'], 'src' | 'width' | 'height'> & {
  src: string;
} & ({
  layout: 'fill';
  width?: never;
  height?: never;
} | {
  layout?: Exclude<Layout, 'fill'>;
  width: string | number;
  height: string | number;
});
```

Let's break this down slightly:

Using the `Omit` utility type we are retrieving all the props that an `img` element can have, then omitting the `src`, `width` and `height` props. This allows us to redefine them in our type.

```ts
Omit<JSX.IntrinsicElements['img'], 'src' | 'width' | 'height'>
```

Next up we define the `src` prop as a required string value. The `&` will merge this with the previous  type.

```ts
& {
  src: string;
}
```

Next up is where the magic happens. We're defining a conditional type, where we're saying that when `layout` is provided with the `'fill'` value it will use the first. Otherwise it'll use the second type.

The `Exclude` utility type is similar to `Omit`. 

```ts
& ({
  layout: 'fill';
  width?: never;
  height?: never;
} | {
  layout?: Exclude<Layout, 'fill'>;
  width: string | number;
  height: string | number;
})
```

Below is the completed example. You'll notice there is also the `toInt` function in order to catch when `width` or `height` is the `never` type instead of passing it directly into the `img` component. 

```tsx
import React, { FC } from 'react';

function toInt(value: unknown): number | undefined {
  if (typeof value === 'number') {
    return value;
  }

  if (typeof value === 'string') {
    return parseInt(value, 10);
  }

  return undefined;
}

type Layout = 'responsive' | 'fill';

type ImageProps = Omit<JSX.IntrinsicElements['img'], 'src' | 'width' | 'height'> & {
  src: string;
} & ({
  layout: 'fill';
  width?: never;
  height?: never;
} | {
  layout?: Exclude<Layout, 'fill'>;
  width: string | number;
  height: string | number;
});

const Image: FC<ImageProps> = ({
  src, width, height, layout, ...rest
}) => {
  const widthInt = toInt(width);
  const heightInt = toInt(height);
  return (
  <img
    src={src}
    width={widthInt}
    height={heightInt}
    className={`layout-${layout}`}
    {...rest}
  />);
}

export default Image;
```

I found this pattern whilst exploring NextJS' Image component: https://github.com/vercel/next.js/blob/canary/packages/next/client/image.tsx, I have attempted to simplify the example here for demonstration purposes.

In this post I also touched on Utility Types (`Exclude` and `Omit` specifically). If you'd like to learn more about them you can see the Typescript documentation: https://www.typescriptlang.org/docs/handbook/utility-types.html

Conditionally required props with Typescript in React

One of the things I like from other languages like PHP is how you can throw and catch specific exceptions. Replicating this in JS/TS however requires a little extra work.

Here's a PHP example for reference:

```php
<?php
class MyException extends Exception { }

function myFunction() {
  throw new MyException('some reason');
}

try {
  myFunction();
} catch (MyException $e) {
  // Handle MyException specifically...
} catch (Exception $e) {
  // Handle all other exceptions
}
```

Now over in JS/TS environments the `try/catch` block doesn't support handling different instances of errors. Instead we'd need to add `if`/`else` or `switch` conditions inside the body of the `catch` in order to handle different cases.

However, in Typescript you cannot simply extend `Error` and expect to be able to use: `if (error instanceof MyError) { }`... Since Typescript 2.1 extending built-ins like `Error`, `Array` and `Map` may not work as you'd expect.

The workaround for this is to call: `Object.setPrototypeOf(this, MyError.prototype)` from within your consructor. Like so:

```ts
class MyError extends Error {
  constructor(message: string) {
    super(message);
    Object.setPrototypeOf(this, MyError.prototype)
  }
}
```

Now the following code will work:

```ts
const myFunction = () => {
  throw new MyError('some reason');
}

try {
  myFunction();
} catch (error) {
  if (error instanceof MyError) {
    // Handle MyError....
  }
}
```

Previously you would have received an instance of `Error` instead of `MyError`.

This is due to how [Typescript handles generating the constructor](https://github.com/Microsoft/TypeScript/wiki/Breaking-Changes#generated-constructor-code-substitutes-the-return-value-of-super-calls-as-this).

This approach to handling errors can produce a bit of nesting in your `catch` block, however it allows to handle each error differently. I find this useful when you're handling multiple scenarios where an error could be thrown, in some instances you may wish to ignore it or hide it.

Consider the following:

```ts
import axios from 'axios';

class JSONAPIError extends Error {
  constructor(message: string) {
    super(message);
    Object.setPrototypeOf(this, MyError.prototype)
  }

  public static fromAxiosError(error: AxiosError) {
    // Surface the detailed error result from our JSON:API compliant api.
    // This error could be more useful to end users
    // Axios error.message contains the status and statusText which
    // isnt useful to users.
    return new JSONAPIError(error.response?.data?.errors[0].detail ?? error.message);
  }
}

const makeApiCall = async (method, url) => {
  try {
    const response = await axios.request({ method, url });
  } catch(error) {
    if (error.response.status === 500) {
      // Notify your error handling system.
      console.error(error);
      // Throw again with a bett
      throw new Error('Internal server error, please try again or contact support');
    }

    throw JSONAPIError.fromAxiosError(error);
  }
}

try {
  const result = await makeApiCall('GET', 'https://google.com/');
  return result;
} catch(error) {
  // A consistent API for handling errors with half decent messages 😍
  window.alert(error.message);
}

```

The above example shows us how we can better control error messages that could be displayed to an end user. Furthermore I'm still exposing the same API you'd expect from `Error`. Axios in this case adds the `response` property where we can access the response from the call that was made, if our code could throw two different errors we'd have the muddy our application logic with checks if certain properties exist. However, I've tucked this away within a function that can be used for making those api calls. Our client that is rendering the error only needs to care about accessing `error.message`. 

Handling custom error classes in Typescript

I recently posted about [developing cloud functions with typescript locally](https://www.ashsmith.io/developing-gcp-cloud-functions-locally-with-typescript). This post is a follow where I've tackled a few other issues you might have when developing multiple functions from a single repo.

For example, as dependencies grow you won't want to include all dependencies for all functions as they may not make use of them. Large dependency lists will slow down the deployment of your functions, and can impact cold start times. I've addressed this using yarn workspaces and following a mono-repo pattern that is common when developing node packages.

This approach means we can develop shared libraries that can be packaged and deployed to a private NPM registry. These can then be be included as dependencies on your functions. Whilst developing locally you won't notice much of a difference.

By using this pattern each function can be packaged with it's own package.json and deployed separately. This brought up a new problem. My previous solution used a `src/index.ts` file which imported and exported all functions and was also used as an entrypoint for all requests when developing locally.

To solve this, I have introduced Docker and Docker Compose. Now each function runs in a standalone container. Each container is mapped to a single nginx container which is how you can trigger your functions. I find this approach a lot nicer. Introducing more technologies into this does complicate a bit though, but I believe this has created a more accurate environment.

Let's get started.

## Initial repo structure:
First up, we'll need to setup our initial repo structure like so:
```
docker/
  functions/
    Dockerfile
    start.sh
src/
  functions/
    http/
      helloWorld/
        index.ts
        index.test.ts
        package.json
  packages/
    lib/
      index.ts
      package.json
.eslintrc.json
.gitignore
docker-compose.yml
package.json
tsconfig.json
```

To create those files form the command line:

```bash
mkdir -p docker/functions
touch docker/functions/{Dockerfile,start.sh}
mkdir -p src/{functions/packages}
mkdir -p src/functions/{event,http}
mkdir -p src/functions/http/helloWorld/{index.ts,package.json}
mkdir -p src/packages/lib/{index.ts,package.json}
touch .eslintrc.json docker-compose.yml package.json tsconfig.json
```

So let's quickly talk about this structure. I've tried to keep a logical structure, so all functions are in the `src/functions/{event-type}/{function-name}/index.ts` format. Supported event-types include: `http` and `event`. This just determines which function signature is used `(req, res) => {}` for http, and `(event, context) => {}` for event.

The `packages` directory is where you can add specific packages that will act as your shared code library. Each directory within here must have it's own `package.json` file which a unique package name. These packages will be scoped, but we'll touch on that more later.

Finally the `docker` and any docker named files all relate to how we'll build and run our docker containers locally. If you don't currently have docker installed now would be a good time to do so. Docker for Mac is recommended if you're on a Mac. Docker for Windows for Windows, and you can just install Docker if you're on linux. If you're not familiar with docker, I won't be going into very much detail here, so I'm sorry if I glaze over it!

## Setting up our package.json files.

Currently we have three `package.json` files: `./package.json`, `src/functions/http/helloWorld/package.json` and `src/packages/lib/package.json`. To get these to work with Yarn Workspaces we'll need to first of all make sure we're running yarn 2 from within our project root:

```bash
yarn set version berry
```
(berry is the code name for yarn 2 at the time of writing)

Note that yarn 2 now uses a different binary for each project rather than a global yarn. There are a number of differences in how yarn 2 works.

With that done, let's create our root package.json with the following:
```json
{
  "name": "functions",
  "version": "0.0.0",
  "description": "",
  "license": "Apache-2.0",
  "keywords": [],
  "private": true,
  "workspaces": [
    "src/packages/*",
    "src/functions/http/*",
    "src/functions/event/*"
  ],
  "scripts": {
    "dev": "yarn install && docker-compose up",
    "test": "mocha -r ts-node/register ./**/*.test.ts",
    "lint": "eslint '**/*.ts'",
    "compile": "tsc",
    "fix": "eslint --fix '**/*.ts'"
  },
  "devDependencies": {
    "@google-cloud/functions-framework": "^1.7.1",
    "@types/chai": "^4.2.14",
    "@types/eslint": "^7.2.4",
    "@types/express": "^4.17.8",
    "@types/mocha": "^8.0.3",
    "@types/node": "^14.11.2",
    "@types/prettier": "^2.1.5",
    "@typescript-eslint/eslint-plugin": "^4.5.0",
    "@typescript-eslint/parser": "^4.5.0",
    "chai": "^4.2.0",
    "chai-http": "^4.3.0",
    "eslint": "^7.11.0",
    "eslint-config-prettier": "^6.13.0",
    "eslint-plugin-node": "^11.1.0",
    "eslint-plugin-prettier": "^3.1.4",
    "express": "^4.17.1",
    "mocha": "^8.2.0",
    "nodemon": "^2.0.4",
    "prettier": "^2.1.2",
    "ts-node": "^9.0.0",
    "typescript": "^4.0.3"
  }
}
```

In your `src/functions/http/helloWorld/package.json` add:

```json
{
  "name": "functions-http-hello-name",
  "version": "0.0.0",
  "description": "",
  "license": "Apache-2.0",
  "keywords": [],
  "main": "build/index.js",
  "rootDir": ".",
  "scripts": {
    "start": "functions-framework",
    "test": "mocha -r ts-node/register ./**/*.test.ts",
    "build": "tsc",
    "tsc:watch": "tsc --watch",
    "prezip": "cp package.json build",
    "zip": "cd build && zip -r ../function.zip ."
  },
  "devDependencies": {
    "@google-cloud/functions-framework": "^1.7.1",
    "@types/chai": "^4.2.14",
    "@types/eslint": "^7.2.4",
    "@types/express": "^4.17.8",
    "@types/mocha": "^8.0.3",
    "chai": "^4.2.0",
    "chai-http": "^4.3.0",
    "eslint": "^7.11.0",
    "express": "^4.17.1",
    "mocha": "^8.2.0",
    "typescript": "^4.0.3"
  }
}
```

You'll notice I have duplicated a number of the devDependencies here. This is because each workspace must declare all of their dependencies explicitly.

Then in our `src/packages/lib/package.json`:
```json
{
  "name": "@ashsmith-funcs/lib",
  "version": "1.0.0",
  "license": "MIT",
  "main": "build/index.js",
  "files": [
    "build/**/*"
  ],
  "types": "build/index.d.ts",
  "scripts": {
    "build": "tsc",
    "tsc:watch": "tsc --watch"
  },
  "devDependencies": {
    "@types/chai": "^4.2.14",
    "@types/eslint": "^7.2.4",
    "@types/express": "^4.17.8",
    "@types/mocha": "^8.0.3",
    "chai": "^4.2.0",
    "chai-http": "^4.3.0",
    "eslint": "^7.11.0",
    "express": "^4.17.1",
    "mocha": "^8.2.0",
    "typescript": "^4.0.3"
  }
}
```

With that done we can now run `yarn install`. You'll notice that there is no longer a `node_modules` directory. This is expected, and part of the new functionality provided by yarn 2.

## Setting up Typescript and linting

Previously I was using `gts` for base Typescript and linting. However using yarn 2 these seemed to break as they depend on the node_modules directory existing. Instead of working around it, I decided to remove it. So lets setup eslint and typescript from scratch this time (using the same configs as gts though for now).

Your `eslintrc.json` will look like this:
```json
{
  "extends": [
    "eslint:recommended",
    "plugin:node/recommended",
    "prettier"
  ],
  "plugins": [
    "node",
    "prettier"
  ],
  "rules": {
    "prettier/prettier": "error",
    "block-scoped-var": "error",
    "eqeqeq": "error",
    "no-var": "error",
    "prefer-const": "error",
    "eol-last": "error",
    "prefer-arrow-callback": "error",
    "no-trailing-spaces": "error",
    "quotes": ["warn", "single", { "avoidEscape": true }],
    "no-restricted-properties": [
      "error",
      {
        "object": "describe",
        "property": "only"
      },
      {
        "object": "it",
        "property": "only"
      }
    ],
    "node/no-unpublished-import": ["error", {
      "allowModules": ["@google-cloud/functions-framework"]
    }]
  },
  "overrides": [
    {
      "files": ["**/*.ts", "**/*.tsx"],
      "parser": "@typescript-eslint/parser",
      "extends": [
        "plugin:@typescript-eslint/recommended"
      ],
      "rules": {
        "@typescript-eslint/no-non-null-assertion": "off",
        "@typescript-eslint/no-use-before-define": "off",
        "@typescript-eslint/no-warning-comments": "off",
        "@typescript-eslint/no-empty-function": "off",
        "@typescript-eslint/no-var-requires": "off",
        "@typescript-eslint/explicit-function-return-type": "off",
        "@typescript-eslint/explicit-module-boundary-types": "off",
        "@typescript-eslint/ban-types": "off",
        "@typescript-eslint/camelcase": "off",
        "node/no-missing-import": "off",
        "node/no-empty-function": "off",
        "node/no-unsupported-features/es-syntax": "off",
        "node/no-missing-require": "off",
        "node/shebang": "off",
        "no-dupe-class-members": "off",
        "require-atomic-updates": "off"
      },
      "parserOptions": {
        "ecmaVersion": 2018,
        "sourceType": "module"
      }
    }
  ]
}
```

I won't deep dive into these rules. The only one I want to note is the `node/no-unpublished-import` rule, where I have explicitly allowed the `@google-cloud/functions-framework`. This is to prevent errors from attempting to load type definitions.

`prettier.json`
```json
{
  "bracketSpacing": false,
  "singleQuote": true,
  "trailingComma": "es5",
  "arrowParens": "avoid"
}
```

Next up, our `tsconfig.json`
```json
{
  "compilerOptions": {
    "lib": ["es2018", "dom"],
    "allowUnreachableCode": false,
    "allowUnusedLabels": false,
    "declaration": true,
    "forceConsistentCasingInFileNames": true,
    "module": "commonjs",
    "noEmitOnError": true,
    "noFallthroughCasesInSwitch": true,
    "noImplicitReturns": true,
    "pretty": true,
    "sourceMap": true,
    "strict": true,
    "target": "es2018",

    "esModuleInterop": true,
    "baseUrl": "src",
    "paths": {
        "@ashsmith-funcs/*": [
          "packages/*"
        ],
    }
  },
  "exclude": ["node_modules", "./**/*.test.ts"]
}
```

Now the important part here is the `compilerOptions.paths` section. Here I have stated that all directories within `src/packages` will be mapped to `@ashsmith-funcs/*` so our packages/lib would be referenced in another package as `@ashsmith-funcs/lib`. You'll notice that this is the same name given in the corresponding package.json. This ensures typescript will look for that directory instead of erroring with an unresolved dependency issue.

## Setting up our first function

Ok, let's get into it with our first http function. In `src/functions/http/helloWorld/index.ts` lets add:

```typescript
import type {HttpFunction} from '@google-cloud/functions-framework/build/src/functions';

export const helloWorld: HttpFunction = (req, res) => {
  res.send('Hello, World!');
};
```

In our test file `index.test.ts`
```typescript
/* eslint-disable node/no-extraneous-import */
import chai from 'chai';
import chaiHttp from 'chai-http';
import express from 'express';
import {helloName} from './';

chai.use(chaiHttp);
chai.should();

const app = express();
app.all('*', helloName);

describe('helloName function', () => {
  describe('GET /', () => {
    it('should get return Hello, World! when no query is provided ', done => {
      chai
        .request(app)
        .get('/')
        .end((err, res) => {
          res.should.have.status(200);
          res.text.should.be.a('string');
          res.text.should.equal('Hello, World!');
          done();
        });
    });
    it('should get return Hello, ash! when the query string is added: ?name=ash', done => {
      chai
        .request(app)
        .get('/?name=ash')
        .end((err, res) => {
          res.should.have.status(200);
          res.text.should.be.a('string');
          res.text.should.equal('Hello, ash!');
          done();
        });
    });
  });
});

```

Now run `yarn test` and make sure it all works!

To test the function locally right now we could also run:
```bash
yarn workspaces functions-http-hello-world run start --target=helloWorld
```

This will start up localhost:8080.

This is great, but what about reloading when file changes happen, and what about developing multiple functions?

Lets dive into docker.

## Docker setup.

For this we'll be using docker-compose to configure our different containers. Let's start by creating our docker images.

`docker/functions/Dockerfile`:
```dockerfile
FROM node:12

COPY ./start.sh /usr/bin/start.sh
RUN chmod +x /usr/bin/start.sh

EXPOSE 8080

USER node
WORKDIR /home/node

RUN yarn set version berry

CMD /usr/bin/start.sh

```

Then our `docker/start.sh` script will look like this:
```bash
#!/bin/bash

npx nodemon \
  --watch src/functions/${EVENT}/${FUNCTION} \
  --exec yarn workspace ${WORKSPACE} run start \
    --signature_type=${EVENT} \
    --source=./build \
    --target=${FUNCTION}

```

The `start.sh` script will run as the main command in the container. This will use nodemon to watch for changes to our project, and reload the functions-framework command. Note the environment variables used here. I'm following a strict naming convention here where by: `src/functions/{event}/{functionName}/index.ts` must exist, and must export a function called `{functionName}`.

With this convention we can reuse this docker image for each of our functions, and it helps with deployment processes too.

With our docker images defined. Let's create the `docker-compose.yml` file:

```yaml
version: '2'

services:
  function-proxy:
    image: ashsmith/function-proxy
    ports:
      - "80:80"
    volumes:
      - /var/run/docker.sock:/tmp/docker.sock:ro
    environment:
      - DEFAULT_HOST=functions.local

  tsc-watch:
    image: ashsmith/functions-framework
    build:
      context: ./docker/functions
    working_dir: /home/node
    volumes:
      - ./:/home/node
    command: ["yarn", "workspaces", "foreach", "-ipa", "run", "tsc:watch"]

  hello-world:
    image: ashsmith/functions-framework
    build:
      context: ./docker/functions
    volumes:
      - ./:/home/node
    environment:
      - FUNCTION=helloWorld
      - EVENT=http
      - WORKSPACE=functions-http-hello-world

```

This file defines three services (or containers):

- `function-proxy` which is a custom nginx server.
- `tsc-watch` this will watch all ts files and compile when they change.
- `hello-world` which is our function.

To get this running:
```bash
docker-compose up [-d]
```

If the images don't exist, it will build them and then boot them up.

The `-d` will run in detached mode, so it runs in the background.

The last thing to do is configure your hosts file so that `127.0.0.1` is mapped to `functions.local`:

On mac / linux:

```bash
echo "127.0.0.1 functions.local" | sudo tee -a /etc/hosts
```

Then go ahead and open `http://functions.local/helloWorld` in your browser.

It's worth noting here the ashsmith/function-proxy image uses jwilder/nginx-proxy docker image as a base. This docker image by default allows you to expose containers via this image onto multiple domains (at least 1 domain per container, no shared domains) for each `VIRTUAL_HOST` environment variable that is defined against a given container.

I have customised the nginx.tmpl file so that we have a single server directive and a single domain, but it generates unique `location` directives per container. Instead of using `VIRTUAL_HOST` I use the `FUNCTION` environment variable to achieve this.

That is how our function `helloWorld` will be available on: `/helloWorld`. Nice!

## Adding a dependency...

Now we have a function working. Let's create some shared code...

`src/packages/lib/index.ts`

```typescript
class Logger {
  public static info(...params: any[]) {
    console.info(...params);
  }
  public static warn(...params: any[]) {
    console.warn(...params);
  }
  public static error(...params: any[]) {
    console.error(...params);
  }
}
export { Logger };

```

Ok.. it's kind of useless, but provides a useful example!

Now let's modify our function to use it:

`src/functions/http/helloWorld/index.ts`

```typescript
import type {HttpFunction} from '@google-cloud/functions-framework/build/src/functions';
import {Logger} from '@ashsmith-funcs/lib';

export const helloWorld: HttpFunction = (req, res) => {
  Logger.info('hello world!');
  res.send('Hello, World!');
};

```

Then add it to your functions package.json:
```
yarn workspace functions-http-hello-world add @ashsmith-funcs/lib
```

Now reload the browser, hopefully the page loads successfully. You can also check the logs output from the `docker-compose up` command. To see if our console.log made it. If you used the `-d` parameter then try: `docker-compose logs -f hello-world` to attach and follow the logs for the helloWorld function.

## Final thoughts.

This approach makes managing dependencies on a per function basis possible. I highly doubt this is the last iteration of the cloud function project for me.

This might be overkill for smaller projects, but it's worth keeping in mind if you wish to keep cold start times down and keep deployments lean.

Combined with the terraform deployment process you'll have a capable environment that has best practices at its core.

With this we also have developed some packages that will need to be published to a private NPM repository. I'll cover this step in a future post! As well as how we will need to modify the deployment strategy (if you've seen my post on [using terraform to deploy cloud functions](https://www.ashsmith.io/provisioning-gcp-cloud-functions-with-terraform) then that will serve as a reasonable starting point.


👋 Hey, I’m Ash!

A Software Engineer and keen triathlete.

Here's some recent^* posts of mine...

Setting up SSH on custom Bitbucket Pipes

Terraform provider for BigCommerce

Introducing ssl-gen a CLI utility for generating self-signed certificates for macOS

Conditionally required props with Typescript in React

Handling custom error classes in Typescript

Improved mono-repo for Typescript + Cloud Function development

👋 Hey, I’m Ash!

A Software Engineer and keen triathlete.

Here's some recent* posts of mine...

Setting up SSH on custom Bitbucket Pipes

Terraform provider for BigCommerce

Introducing ssl-gen a CLI utility for generating self-signed certificates for macOS

Conditionally required props with Typescript in React

Handling custom error classes in Typescript

Improved mono-repo for Typescript + Cloud Function development

Here's some recent^* posts of mine...