npm package: @postnord/web-components
Description: PostNord Web Components
Latest version: 7.24.0

# PostNords web component library

This repo utilizes the Web Components compiler Stencil.js. The goal is to be able to provide re-usable components that the PostNord web teams can use to save time and get a holistic design. These components can be used in any popular framework or with no framework at all.

The library is intended to work with any other CSS framework you wish to use. As long as the CSS class names do not begin with "pn-" there should be no issues at all. However, we do recommend that you use the [pn-design-assets package](https://www.npmjs.com/package/pn-design-assets) which the libary was intended to be used with. The design assets include fonts, icons and more that helps you get started.

## Documentation

The library is documented with the help of Storybook. You can view [the latest documentation here](https://portal.postnord.com/web-components/).

Quick links:

- [Using PostNord Web Components in your project](https://portal.postnord.com/web-components/?path=/docs/docs-installation--docs)
- [Get started with PostNord design assets](https://portal.postnord.com/web-components/?path=/docs/docs-assets--docs)

### localhost Web Components in codepen.io

- To try out your localhost Web Components in codepen.io, you can run

```bash
# start exposed server at https://localhost:8000
npm run exposed
```

First time you need to go to https://localhost:8000 and accept the SSL warning.

Add the following code to the HTML section in codepen.io

```html
<!-- If you want to register all componets we have at once -->
<script type="module" src="https://localhost:8000/postnord-web-components.esm.js"></script>
```

## Infrastructure as Code (IaC)
Defining infrastructure in code makes your setup repeatable, reviewable, and recoverable. You get the same stack every time (no snowflake environments), changes go through code review, and you can recreate or roll back environments quickly if something goes wrong.

This project uses Open Serverless Framework with AWS CloudFormation under the hood to provision:

* An S3 bucket for static content
* A CloudFront distribution (with OAC) in front of the bucket
* Locked-down bucket policies tied to the distribution

### Prerequisites

* AWS credentials configured locally with permissions to deploy CloudFormation stacks, S3, CloudFront.

### Environments & Stages

We use two Serverless stages:
* test – integration/sanity checks
* prod – live environment

The stack name is ${service}-${stage} (e.g., web-components-test, web-components-prod).

### One-time Setup

#### Deploy the test stage (default in this repo is "test")
```bash
npx sls deploy --stage test
```

#### Deploy to prod
When you’re happy with test, promote to prod:

```bash
npx sls deploy --stage prod
```

### Updating the Stack

Make changes to serverless.yml (e.g., cache policies, priceClass: PriceClass_100, OAC/OAI choices, custom domain). Then:

##### test
```bash
npx sls deploy --stage test
```

##### prod
```bash
npx sls deploy --stage prod
```

### Tearing Down

To delete the stack and all managed resources:

#### test
```bash
npx sls remove --stage test
```

#### prod
```bash
npx sls remove --stage prod
```

Be careful—this removes the CloudFormation stack and may delete the S3 bucket contents if the bucket is not retained.