<Image src="git.jpg" alt="Hand-drawn illustration of the Git logo inside a tilted square outline with three red dots connected by black lines, representing branches" priority={true} />

When it comes to managing version control in your project with Git, `.gitignore` files typically handle most cases of
excluding specific files or directories from being tracked. However, there are instances when you either can’t or simply
prefer not to modify the `.gitignore` file directly.

Fortunately, Git offers several alternative methods to tackle these scenarios effectively.

### Why You Might Want to Avoid Modifying .gitignore

There are generally two key situations where you might opt to keep your `.gitignore` unchanged:

1. **Personal or local-specific files:** Say you have custom settings or environment files (like `.envrc` or
 personalized
 IDE configurations). You wouldn’t want to clutter the repository with your personal preferences that aren’t relevant
 to others.
2. **Temporarily ignoring changes to tracked files:** Perhaps you’re making adjustments to a file that’s already under
 version control (such as a Docker configuration or database settings), but you want to ensure these changes don’t
 appear in every commit.

Here’s how to handle both situations gracefully.

### Ignoring untracked files

Git provides a straightforward solution that keeps personal preferences out of sight from collaborators: the
`.git/info/exclude` file. This file acts just like `.gitignore` but remains local—meaning your teammates won’t be
affected
by your individual exclusions.

To put this into action, simply open the `.git/info/exclude` file in your repository and list the files or directories
you
wish to ignore:

```gitignore
.idea/
*.log
.env.local
```

Now, your IDE settings, log files, or local environment configurations will no longer clutter your Git status or lead to
accidental commits without interrupting your teammates’ workflow.

### Temporarily Ignoring Changes with git update-index

At some point, you’ll find it necessary to tweak files you’re already tracking, but you have no intention of committing
those changes (for example, adjusting local ports or temporary debugging code). That’s where the
`git update-index --assume-unchanged` command comes in.

Here’s how it works:

To temporarily ignore changes in a tracked file, simply run:

```bash
git update-index --assume-unchanged docker-compose.yml
```

This command tells Git to overlook any further changes made to `docker-compose.yml`, treating it as if it hasn’t been
modified.

However, use this feature with caution! Overuse can lead to confusion, especially if you forget you’ve set it. To resume
tracking the changes, you can run:

```bash
git update-index --no-assume-unchanged docker-compose.yml
```

If you ever need a quick way to check which files are being ignored, you can use:

```bash
git ls-files -v | grep '^h'
```

This command lists the files that Git currently assumes are unchanged, helping you maintain organization.

### Final Thoughts

While `.gitignore` is a powerful tool, it’s not always enough on its own. By incorporating `.git/info/exclude` and the
`git update-index` technique into your toolkit, you can enjoy greater flexibility in managing your repository.

Precise management leads to fewer headaches and cleaner commits, ensuring a smoother and more intuitive approach to
version control.

Learn about Git's hidden alternatives to .gitignore for managing file exclusions locally without affecting your team's workflow.

When .gitignore Isn't the Right Tool

Let’s talk about version numbers in your `package.json`. You’ve probably seen versions like `1.2.3` or `^4.5.0`—but what
do they *actually* mean?

<Image src="semver.jpg" alt="but it works on *my* machine joke" />

---

## **SemVer: The Three-Number System That Keeps Everyone Sane**

Semantic Versioning (SemVer) is just a fancy way of saying: 
**“Hey, let’s use version numbers to tell people what *kind* of changes we made.”**

Versions look like `x.y.z`:

- **Major (x)**: Big changes that might break your code. *Example:* Removing a feature your app relies on.
- **Minor (y)**: New stuff that won’t wreck existing code. *Example:* Adding a cool new function.
- **Patch (z)**: Quiet fixes for bugs or security holes. *Example:* Fixing a crash when you type `null`.

Think of it like home renovations:

- **Major** = Tearing down a wall (big impact).
- **Minor** = Adding a new room (no harm done).
- **Patch** = Fixing a leaky faucet (everyone’s happy).

---

## **Why Should You Care?**

Because npm uses these numbers to decide which updates are safe to install automatically. If everyone follows SemVer,
your app won’t suddenly break when you run `npm update`.

---

## **The Secret Symbols in Your package.json**

Those weird characters like `^` and `~` in your dependencies? They’re just rules for npm. Here’s what they *really*
mean:

- **`^1.2.3`** = “New features and fixes are okay, but don’t change anything big!” 
 *(Updates to 1.3.0 or 1.2.4 are fine. Won’t jump to 2.0.0.)*

- **`~1.2.3`** = “Only tiny fixes, please.” 
 *(Updates to 1.2.4 are okay. Won’t go to 1.3.0.)*

- **`>` or `>=`** = “Give me anything newer than this.”
- **`<` or `<=`** = “Nothing newer than this, thanks.”
- **`1.2.3` - `1.5.0`** = “I’ll take any version between these two.”
- **`||`** = “Either version A *or* version B works.”

**No symbol?** Example: `"lodash": "4.17.21"` means *“Only this exact version. Don’t change a thing!”*

---

## **Real-World Tips for Humans**

1. **Start with `^`** for most dependencies. It’s the safest way to get bug fixes and new features without surprises.
2. **Use exact versions** for critical packages (like React or Vue) where unexpected changes could ruin your day.
3. **Check `npm outdated` weekly** to see which packages have updates. It’s like a to-do list for your app’s health.
4. **Commit `package-lock.json`** to avoid “but it works on *my* machine” moments. This file locks down every tiny
 detail.

<Image src="ops.jpg" alt="but it works on *my* machine joke" />

## **When Things Go Sideways**

- **Broke after an update?** Check if a major version sneaked in. Temporarily pin the version `"package": "1.2.3"`
 until you fix things.
- **Confused by symbols?** Use [semver.org](https://semver.org/) to understand semantic versioning rules.

---

## **Quick Cheat Sheet**

| Symbol | What It Means | 
|----------|-------------------------------------------| 
| `^1.2.3` | “Keep me up to date, but no big changes!” | 
| `~1.2.3` | “Only bug fixes, please.” | 
| `1.2.x` | “Any patch version for 1.2.” | 

---

## **Wrapping Up**

SemVer isn’t about memorizing rules—it’s about communicating changes clearly. Use `^` for flexibility, `~` for caution,
and exact versions when stability matters. And always, *always* check your `package-lock.json` into Git.

**Try this now:**

```bash 
npm outdated 
``` 

See what updates are waiting? Update one with `npm update package-name` and see if your app still works. You’ve got
this! 🛠️

--- 

*P.S. Sharing is caring. Forward this to a teammate who still edits `package.json` versions by hand. 😉*

## Related Articles

- [Migrate to pnpm](/blog/pnpm) - faster package management with better disk efficiency
- [Conventional Commits](/blog/conventional-commits) - structured commit messages for automated versioning

A friendly, practical guide to SemVer in npm. Learn versioning rules, avoid dependency chaos, and manage updates with confidence.

Mastering npm and Semantic Versioning for Smarter Development


Writing clean, maintainable JavaScript isn't just about making your code work - it's about making it understandable. In
this comprehensive guide, we'll explore the essential naming conventions that can transform your JavaScript code from
merely functional to professionally polished.

## Why Naming Matters in JavaScript

Every time you write code, you're not just writing it for the computer - you're writing it for other developers (
**including your future self** ). Good naming conventions serve as a form of documentation, making your code self-explanatory
and reducing the cognitive load required to understand it.

## Core Principles of JavaScript Naming

### 1. Consistency Is Key

The most fundamental rule of naming in JavaScript is maintaining consistency throughout your project. Whether you choose
camelCase or snake_case, stick to it. Here's why:

- Reduces cognitive overhead for developers
- Makes code more predictable
- Simplifies maintenance and refactoring
- Improves team collaboration

### 2. Language Matters

While JavaScript is flexible enough to allow variable names in any language, stick to English. This ensures:

- Universal code readability
- Easier collaboration with international teams
- Better integration with existing codebases

### 3. The Case for Different Cases

JavaScript uses multiple naming conventions depending on the context:

- `camelCase` for variables, functions, and methods
- `PascalCase` for classes and constructor functions
- `UPPER_SNAKE_CASE` for constants
- `kebab-case` typically for CSS classes and HTML attributes

JavaScript’s built-in APIs use camelCase (e.g., getElementById), PascalCase for classes (e.g., Date), and UPPER_SNAKE_CASE for constants (e.g., Math.PI). Align your code with these patterns.

## Practical Naming Guidelines

### Variables and Functions

#### Boolean Variables

Boolean variables should start with an affirmative prefix, typically 'is' or 'has':

```javascript
// Bad ❌
const active = true;
const notAllowed = !user.checkAccess();

// Good ✅
const isActive = true;
const hasPermission = user.checkAccess();
```

> Another thing to remember at the conference is that the affirmative prefix shouldn't include a negation. This is because the negation operator (!) is most commonly used with Boolean values. So, a value named something like 'isNotAllowed' with the negation applied to it, '!isNotAllowed', can be quite misleading.

Naming recommendations for Boolean from [W3C](https://w3ctag.github.io/design-principles/#naming-booleans).

#### Functions and Methods

Function names should be verbs that clearly describe their action:

```javascript
// Bad ❌
function userData() {}

function total() {}

// Good ✅
function getUserData() {}

function calculateTotal() {}
```

### Collections and Arrays

Use plural nouns for arrays and collections:

```javascript
// Bad ❌
const userRoleList = ['admin', 'editor', 'viewer'];
const activeUserArr = new Set();

// Good ✅
const userRoles = ['admin', 'editor', 'viewer'];
const activeUsers = new Set();
```

### Classes and Objects

#### Class Names

Classes should use PascalCase and be noun phrases:

```javascript
// Bad ❌
class userService {
  constructor() {}
}

// Good ✅
class UserService {
  constructor() {}
}
```

#### Class Members

Avoid repeating the class name in member names:

```javascript
// Bad ❌
class UserProfile {
  updateUserProfile() {}

  deleteUserProfile() {}
}

// Good ✅
class UserProfile {
  update() {}

  delete() {}
}
```

### Constants and Enums

#### Constants

Use UPPER_SNAKE_CASE for true constants:

```javascript
// Bad ❌
const maxRetryAttempts = 3;
const apiBaseUrl = 'https://api.example.com';

// Good ✅
const MAX_RETRY_ATTEMPTS = 3;
const API_BASE_URL = 'https://api.example.com';
```

#### Enums

Use PascalCase for enum names and UPPER_SNAKE_CASE for enum values:

```javascript
// Bad ❌
const userRoles = {
  admin: 'admin',
  editor: 'editor',
  viewer: 'viewer'
};

// Good ✅
const UserRole = {
  ADMIN: 'admin',
  EDITOR: 'editor',
  VIEWER: 'viewer'
};
```

#### Maps
Also known as a dictionary data structure. This data structure is used for mapping one value to another.

```javascript
// Bad ❌
const userRole = {
  [AccountType.SUPERVISOR]: 'Supervisor',
  [AccountType.VISITOR]: 'Visitor',
}

const REDIRECTING = {
  '/teams': '/supervisor-panel',
  '/account': '/authenticate',
}

const UserPermissions = {
  [AccountType.SUPERVISOR]: [AccessLevel.USER_ADMINISTRATION, AccessLevel.TEAM_ADMINISTRATION],
  [AccountType.VISITOR]: [AccessLevel.PROFILE_MANAGEMENT],
}

// Good ✅
const userRoleToReadable = {
  [AccountType.SUPERVISOR]: 'Supervisor',
  [AccountType.VISITOR]: 'Visitor',
}

const pagePathToRedirectPath = {
  '/teams': '/supervisor-panel',
  '/account': '/authenticate',
}

const userRoleToPermissions = {
  [AccountType.SUPERVISOR]: [AccessLevel.USER_ADMINISTRATION, AccessLevel.TEAM_ADMINISTRATION],
  [AccountType.VISITOR]: [AccessLevel.PROFILE_MANAGEMENT],
}
```

## Common Pitfalls to Avoid

### 1. Including Types in Names

```javascript
// Bad ❌
const userArray = ['John', 'Jane'];
const nameString = 'John';

// Good ✅
const users = ['John', 'Jane'];
const name = 'John';
```

### 2. Ambiguous Abbreviations

```javascript
// Bad ❌
const usr = getUser();
const pwd = 'secret';

// Good ✅
const user = getUser();
const password = 'secret';
```

### 3. Inconsistent Naming Patterns

```javascript
// Bad ❌
const get_user = () => {};
const fetchData = () => {};
const retrieve_info = () => {};

// Good ✅
const getUser = () => {};
const fetchData = () => {};
const retrieveInfo = () => {};
```

### 4. Different Languages
```javascript
// Bad ❌
const ユーザー名 = "John";

// Good ✅
const userName = "John";
```

## Types & Interfaces

Names of types and interfaces should be written in `PascalCase` notation.

```typescript
// Bad  ❌
type TUser = {
  firstName: string
  lastName: string
}

interface userServiceInterface {
  findByEmail: (email: string) => User
}

// Good ✅
type User = {
  firstName: string
  lastName: string
}

interface UserServiceContract {
  findByEmail: (email: string) => User
}

interface IUserService {
  findByEmail: (email: string) => User
}
```

> When engineering teams choose to leverage both class-based types and abstract definitions within the same project, best practices suggest adding a distinguishing marker to the abstract definitions. Common prefix choices include `T` and `Contract`.

## Tools for Maintaining Naming Conventions

To help maintain consistent naming conventions, consider using:

1. [ESLint](https://eslint.org/) with naming convention rules
2. [Prettier](https://prettier.io/) for consistent formatting
3. IDE extensions for code style enforcement
4. Team code review guidelines focused on naming

## Time Tested Naming Naming Conventions
- [Google TypeScript Style Guide](https://google.github.io/styleguide/tsguide.html#naming)
- [Airbnb JavaScript Style Guide](https://github.com/airbnb/javascript?tab=readme-ov-file#naming-conventions) 

## Conclusion

Good naming conventions are more than just style preferences - they're a fundamental aspect of writing maintainable,
professional JavaScript code. By following these conventions consistently and thoughtfully, you'll create code that's
easier to understand, maintain, and debug.

Remember, the goal isn't to follow these rules blindly, but to use them as guidelines to write more readable and
maintainable code. The best naming convention is one that your entire team understands and follows consistently.

## Related Content

- [CSS Class Naming Conventions](/blog/class-naming-conventions) - BEM methodology for HTML/CSS
- [Common CSS Class Names](/snippets/common-css-classes) - practical BEM class name examples


Master JavaScript naming conventions with this guide. Learn best practices for naming variables, functions, and classes to write cleaner code.

JavaScript Naming Conventions: A Complete Guide for Clean Code

<Image src="conventional-commits.jpg" alt="Conventional Commits. A close up of a text description on a computer screen." />

I first came across Conventional Commits during my time at [MacPaw](/about), but initially, I didn't give much thought
to these unique commit messages.
It wasn't until recently that I took a closer look and realized how much more efficient and organized they make the
development process.

Here’s why you might want to give them a try too! 😃

## What Are Conventional Commits?

Conventional Commits is a specification that provides a simple, structured convention for commit messages.
It allows to write messages that are easy to read and maintain, and which convey the specific intent behind each
change.

The conventional commit message format is straightforward. It starts with a **type**, optionally followed by a **scope
**, and a
short **description**. For example:

```bash
feat(login): add authentication with JWT
```

In this example:

- `feat` is the type of the commit, indicating a new feature.
- `login` is the scope, specifying the part of the project that is affected.
- `add authentication with JWT` is the short description of the change.

## Why Use Conventional Commits?

Using Conventional Commits offers several key benefits:

- `Consistency`: Standardized commit messages ensure that everyone on the team follows the same format, which enhances
 readability and reduces ambiguity.
- `Automation`: Tools can automatically generate change logs, version numbers, and releases based on the structured
 commit messages.
- `Collaboration`: Clear and descriptive commit messages help team members understand the history and context of
 changes, improving collaboration.
- `Compliance`: Adhering to a standardized format helps in meeting the guidelines and best practices of many open-source
 projects.

## Types of Conventional Commits

There are several predefined types of Conventional Commits that help categorize the nature of each change. Each type
indicates a specific kind of modification, making it easier to understand the impact of the commit. Here are the most
commonly used types:

- **feat**: A new feature for the user.
- **fix**: A bug fix for the user.
- **chore**: Changes that don't modify src or test files, such as updating build tasks.
- **docs**: Documentation-only changes.
- **style**: Changes that do not affect the meaning of the code (e.g., formatting, missing semicolons, etc.).
- **refactor**: A code change that neither fixes a bug nor adds a feature.
- **perf**: A code change that improves performance.
- **test**: Adding or updating tests.
- **build**: Changes that affect the build system or external dependencies (e.g., gulp, npm).
- **ci**: Changes to CI configuration files and scripts (e.g., CircleCI, Travis).
- **revert**: Reverts a previous commit.

## Cheat Sheet for Conventional Commits

<Image src="conventional-commits-cheatsheet.png" alt="Conventional Commits Cheatsheet" />

| Type | Description | Example |
|:---------|:---------------------------|:---------------------------------|
| feat | New feature | feat(ui): add dark mode |
| fix | Bug fix | fix(api): resolve login issue |
| docs | Documentation only changes | docs(readme): update setup guide |
| style | Code style changes only | style(css): format CSS classes |
| refactor | Code refactoring | refactor(auth): optimize logic |
| perf | Performance improvement | perf(database): optimize queries |
| test | Adding tests | test(routes): add unit tests |
| chore | Build tool/config changes | chore(deps): bump dependencies |
| ci | Continuous Integration | ci(travis): update config |
| revert | Revert previous commit | revert: rollback last change |

## Leveraging AI with Conventional Commits

AI-powered IDEs like **JetBrains'** suite of tools enhances your workflow by intelligently suggesting commit messages that
adhere to Conventional Commits standards. These suggestions are contextually generated based on changes you've made,
significantly streamlining the process and reducing the cognitive load of writing detailed commit messages.

### AI-Powered IDEs and Conventional Commits

JetBrains IDEs, such as IntelliJ IDEA and WebStorm, integrate [AI tools](https://www.jetbrains.com/ai-assistant/) that:

- Automatically suggest precise commit messages.
- Detect commit types (feat, fix, docs, etc.) based on changes.
- Recommend appropriate scopes, improving accuracy and efficiency.

## Examples of Conventional Commits

Understanding the theory behind Conventional Commits is one thing, but seeing how they are applied in real-world
scenarios can be extremely helpful. Below are some examples illustrating how to write effective, clear, and standardized
commit messages.

> Here example of commits from [my GitHub](https://github.com/Shramkoweb/Portfolio/commits/develop/)

### Example 1: Adding a New Feature

**Commit Message**:

```bash
feat(auth): add OAuth 2.0 authentication
```

**Explanation**:

**Type**: `feat` (indicates a new feature). 
**Scope**: `auth` (specifies that the change is related to authentication). 
**Description**: `add OAuth 2.0 authentication` (brief summary of the change).

### Example 2: Fixing a Bug

**Commit Message**:

```bash
fix(profile): resolve issue with avatar upload
```

**Explanation**:

**Type**: `fix` (indicates a bug fix). 
**Scope**: `profile` (specifies that the change affects the profile feature). 
**Description**: `resolve issue with avatar upload` (briefly describes the problem and solution).

### Example 3: Updating Documentation

**Commit Message**:

```bash
docs(readme): update installation instructions
```

**Explanation**:

**Type**: `docs` (indicates a documentation change). 
**Scope**: `readme` (specifies the README file). 
**Description**: `update installation instructions` (details the specific update).

### Example 4: Refactoring Code

**Commit Message**:

```bash
refactor(utils): simplify the date parsing logic
```

**Explanation**:

**Type**: `refactor` (indicates a code change that neither fixes a bug nor adds a feature). 
**Scope**: `utils` (specifies that the change pertains to utility functions). 
**Description**: `simplify the date parsing logic` (briefly describes the refactoring).

### Example 5: Performance Improvement

**Commit Message**:

```bash
perf(db): optimize query execution time
```

**Explanation**:

**Type**: `perf` (indicates a performance improvement). 
**Scope**: `db` (specifies that the change affects the database). 
**Description**: `optimize query execution time` (summarizes the performance enhancement).

### Example 6: Adding or Updating Tests

**Commit Message**:

```bash
test(router): add unit tests for routing module
```

**Explanation**:

**Type**: `test` (indicates test-related changes). 
**Scope**: `router` (specifies the routing module). 
**Description**: `add unit tests for routing module` (briefly describes the tests added).

### Example 7: Maintenance or Chore

**Commit Message**:

```bash
chore(deps): upgrade lodash to version 4.17.21
```

**Explanation**:

**Type**: `chore` (indicates maintenance or chores). 
**Scope**: `deps` (specifies that the change pertains to dependencies). 
**Description**: `upgrade lodash to version 4.17.21` (details the specific update).

### Example 8: Continuous Integration Configuration

**Commit Message**:

```bash
ci(circleci): add build step for linting
```

**Explanation**:

**Type**: `ci` (indicates changes to CI configuration). 
**Scope**: `circleci` (specifies the CI service being configured). 
**Description**: `add build step for linting` (briefly describes the new CI step).

### Example 9: Reverting a Previous Commit

**Commit Message**:

```bash
revert: remove OAuth 2.0 authentication

This reverts commit abc123.
```

**Explanation**:

**Type**: `revert` (indicates the commit is a revert). 
**Scope**: None (reverts don't usually need a scope). 
**Description**: `remove OAuth 2.0 authentication` (describes what is being reverted).
Body: This reverts commit abc123. (provides context by specifying the commit being reverted).

## Using Conventional Commits in Projects

Incorporating Conventional Commits into your projects can significantly improve code quality and team collaboration.
Here’s a step-by-step guide on how to start using Conventional Commits in your projects.

### Step 1: Educate Your Team

Before adopting Conventional Commits, ensure that everyone on your team understands its benefits and guidelines. Share
resources, conduct workshops, or organize short training sessions to help everyone get up to speed.

### Step 2: Set Up Commit Message Linting

To enforce the Conventional Commits standard, you can use tools
like [commitlint](https://github.com/conventional-changelog/commitlint) and [husky](https://typicode.github.io/husky/).
These tools help ensure that
all commit messages adhere to the predefined format.

Example Configuration:

#### Install Dependencies:

```bash
npm install --save-dev @commitlint/config-conventional @commitlint/cli husky
```

#### Configure Commitlint:

Create a new file named `commitlint.config.js` in the root of your project and add the following content:

```js
module.exports = {
 extends: ['@commitlint/config-conventional'],
};
```

#### Set Up Husky Hooks:

The `init` command simplifies setting up husky in a project. It creates a `pre-commit` script in `.husky/` and updates
the prepare script in `package.json`. Modifications can be made later to suit your workflow.

```bash
npx husky init
```

### Step 3: Use Tools and Libraries

Conventional commits can be parsed by tools, and a very nice use-case is that of generating release changelogs.

<Image src="changelog.png" alt="Changelog created from Conventional commits on GitHub page" />

#### Semantic Release:

- Automates the whole package release workflow including determining the next version number, generating the release
 notes, and publishing the package.
- [Semantic Release Documentation](https://semantic-release.gitbook.io/semantic-release)

#### Commitizen:

- A tool that prompts you to fill out the commit message with a CLI, ensuring you follow the Conventional Commits
 standard.
- [Commitizen Documentation](https://github.com/commitizen/cz-cli)

### Step 4: Continuous Integration and Continuous Deployment (CI/CD)

Integrate Conventional Commits with your `CI/CD` pipeline to automate tasks such as generating changelogs and
versioning.

Here’s how you can do it:

#### Changelog Generation:

- Use tools like standard-version to generate changelogs automatically.
- [Standard Version Documentation](https://github.com/conventional-changelog/standard-version)

#### Versioning and Releasing:

- Automate versioning and releasing using tools like Semantic Release.
- Define release steps in your CI configuration (e.g., GitHub Actions, Travis CI).

Example GitHub Actions Configuration for Semantic Release:

```yaml
name: Release
on:
 push:
 branches:
 - main
jobs:
 release:
 runs-on: ubuntu-latest
 steps:
 - name: Checkout Code
 uses: actions/checkout@v2
 - name: Install Node.js
 uses: actions/setup-node@v2
 with:
 node-version: 14
 - name: Install Dependencies
 run: npm install
 - name: Run Semantic Release
 run: npx semantic-release
 env:
 GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
```

## Conclusion

I hope this blog post has inspired you to delve into conventional commits.

Initially, conventional commits might seem a bit odd, and you might find yourself questioning the format as you make
commits. However, they soon become second nature, and you'll appreciate their impact on your software engineering
practices.

> Conventional commits pair well with [Semantic Versioning](/blog/npm-semantic-versioning) for automated package releases.

Master Conventional Commits to write clear, structured commit messages. Learn the format, types like feat and fix, and how to automate changelog generation.

Conventional Commits enhance your coding practices

## Introduction

<Image src="pnpm-logo.png" alt="pnpm logo on gay background" />

I found article from Vercel
about [Projects using pnpm can now be deployed with zero configuration](https://vercel.com/changelog/projects-using-pnpm-can-now-be-deployed-with-zero-configuration)
and I wanted to try it.

## Why Migrate to pnpm?

Before diving into the migration process, it’s important to understand why pnpm is beneficial:

1. **Speed** 🚀: pnpm installs dependencies faster than npm by using a unique package linking mechanism.
2. **Disk Space** 🔎: It saves disk space by using a global store and hard links.
3. **Consistency** 💡: pnpm ensures that dependencies are installed in a way that is more consistent with the version
 specified in your `package.json`.

## Installation of pnpm

First, you need to install pnpm globally. You can do this by running:

```bash
brew install pnpm
```

## Migration Steps

### 1. Clean the Project

Remove the `node_modules` directory and the `package-lock.json` file. This step is crucial to ensure that there are no
leftover artifacts from npm that might interfere with pnpm.

```bash
rm -rf node_modules package-lock.json
```

### 2. Initialize pnpm

Run the following command to initialize pnpm in your project directory:

```bash
pnpm install
```

This command will create a `pnpm-lock.yaml` file and install all the dependencies listed in your `package.json`.

### 3. Verify Dependency Installation

Check that all dependencies have been installed correctly by running:

```bash
pnpm list
```

This command lists all the installed dependencies and their versions. Make sure that there are no missing or outdated
packages.

<Image src="pnpm-list.png" alt="pnpm list command result in terminal" />

## Updating Scripts

### 1. Update npm Scripts

In your `package.json`, update any npm scripts to use pnpm where necessary. For example, if you have a script for
installing dependencies, change it from:

```json
"scripts": {
"install": "npm install"
}
```

to:

```json
"scripts": {
"install": "pnpm install"
}
```

### 2. Update CI/CD Pipelines

If your project uses CI/CD pipelines, ensure that the build scripts and installation commands are updated to use pnpm.
For example, in a [GitHub Actions with pnpm](https://pnpm.io/continuous-integration) workflow, you might update the
step as follows:

```yaml
jobs:
 build:
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v4
 - uses: pnpm/action-setup@v4
 with:
 version: 9
 - uses: actions/setup-node@v4
 with:
 node-version: ${{ matrix.node-version }}
 cache: 'pnpm'
 - name: Install
 run: pnpm i
 - name: Run Tests // All your CI commands
 run: pnpm run test
```

## Handling Issues and Troubleshooting

During the migration, you might encounter some issues.

> Error: Unable to locate executable file: pnpm. Please verify either the file path exists or the file can be found
> within a directory specified by the PATH environment variable. Also check the file mode to verify the file is
> executable.

I stuck with this error when I tried to run the `pnpm` command in GitHub Actions.

The solution was to use the `pnpm/action-setup@v4` before `actions/setup-node@v4`.
So simply just copy the [above code](#2-update-cicd-pipelines) and paste it in your `.yml` file.

## Conclusion

This migration helped me to reduce the time of deployment by **44%** and the size of `node_modules` by **5%**.

<Image src="vercel-deployment.png" alt="Deployment time on vercel dashboard. Around 1 seccond" />

More info how my blog works you can find there [How my site works under the hood](./introducing-the-new-shramko.dev)

Migrate from npm to pnpm and cut your deployment time by 44%. Step-by-step guide covering installation, lockfile conversion, and CI/CD configuration.

Migrate from npm to pnpm – Save Time with This Guide

<Image src="keys.jpg" alt="Keys on white background" />

Hello everyone!

Today, we are going to walk through the process of adding [SSH keys](https://www.ssh.com/academy/ssh-keys) to a GitHub
account using the modern and secure ed25519 algorithm.

Before we begin, make sure you have Git installed on your system. If you haven't done this already, head over to
the [Git website](https://git-scm.com/install/), download the latest version, and install it.

Here is a step-by-step guide:

### Step 1: Checking for Existing SSH keys

Before creating new SSH keys, check if you already have any pre-existing keys. Open your Git terminal or command line
and type:

```bash
$ ls -al ~/.ssh
```

<Image src="ssh.jpg" alt="macOS terminal with .ssh folder" />

This command lists all the files in your .ssh directory. If you don't find any, you can proceed to generate a new one.

Your SSH keys might use one of the following algorithms:

- ⛔️ DSA: It's unsafe and even no longer supported since OpenSSH version 7, you need to upgrade it!
- 🥴 RSA: It depends on key size. If it has 3072 or 4096-bit length, then you're good. Less than that, you probably want
 to upgrade it. The 1024-bit length is even considered unsafe.
- 👌 ECDSA: It depends on how well your machine can generate a random number that will be used to create a signature.
 There's also a trustworthiness concern on the NIST curves that being used by ECDSA.
- 🥳 Ed25519: It's the most recommended public-key algorithm available today! This is what we'll use in this guide.

### Step 2: Generating a New SSH key

In your terminal, paste the following command:

```bash
$ ssh-keygen -t ed25519 -C "shramko.dev@gmail.com"
```

Replace `shramko.dev@gmail.com` with the email address you used to create your GitHub account. Then, you will be
prompted to "Enter a file in which to save the key," - press Enter to accept the default file location.

**Note:** If you're using a legacy system that doesn't support ed25519, you can use RSA with 4096 bits instead:

```bash
$ ssh-keygen -t rsa -b 4096 -C "shramko.dev@gmail.com"
```

### Step 3: Adding Your SSH key to the ssh-agent

Make sure the `ssh-agent` is running:

```bash
$ eval "$(ssh-agent -s)"
```

Then, add your new SSH key to the ssh-agent:

```bash
$ ssh-add ~/.ssh/id_ed25519
```

Note: If you used RSA instead, replace "id_ed25519" with "id_rsa".

### Step 4: Adding the SSH key to Your GitHub Account

1. Go to your GitHub account settings.
2. Click on 'SSH and GPG keys' in the menu on the left-hand side.
3. Click on 'New SSH Key'.
4. Title it appropriately, then copy the SSH public key to the 'Key' input.

To copy the SSH key, go back to your terminal and type:

```bash
$ clip < ~/.ssh/id_ed25519.pub
```

**For Linux users, use:**
```bash
$ cat ~/.ssh/id_ed25519.pub
```

**For macOS users, you can also use:**
```bash
$ pbcopy < ~/.ssh/id_ed25519.pub
```

Paste the key into the 'Key' input on GitHub, then click 'Add SSH Key'.

### Step 5: Testing the Connection

Return to your terminal and type:

```bash
$ ssh -T git@github.com
```

<Image src="gh.jpg" alt="Testing the Connection with GitHub in macOS terminal" />

You should see a message welcoming you: "Hi [Your GitHub username]! You've successfully authenticated, but GitHub does
not provide shell access."

You've now successfully added a modern, secure ed25519 SSH Key to your GitHub account.

Learn how to add SSH keys to your GitHub account. Boost security and ease your workflow by connecting your local machine to GitHub repositories.

Adding SSH Keys to Your GitHub Account

<Image src="browsers.jpg" alt="Different browsers logo on gradient background" />

During site development, we usually test our site only in the browser installed on our computer, but in the world of
browsers there are dozens, and maybe even thousands, of versions.

Therefore, cross-browser development and testing are considered a good tone in site development.

## Cross-browser development

Cross-browser development is when your site works not only in the latest Google Chrome, but also in Firefox, Safari,
Opera and Microsoft Edge, plus mobile browsers and tablets.

There are many methods and ways for such development, such
as [vendor prefixes](https://developer.mozilla.org/en-US/docs/Glossary/Vendor_Prefix), [polyfills](https://developer.mozilla.org/en-US/docs/Glossary/Polyfill),
responsive design and [much more](https://ishadeed.com/article/cross-browser-development/).

I will write about all this in the next article, and today we will talk only about cross-browser testing and tools.

## Cross-browser testing

But how to check that the site you created looks and works the same on different browsers and devices?

The first thought that comes to mind is to install all your browsers on your computer and check everything there, but
there are several limitations here:

- Browser versions ( Usually you install the latest version )
- Operating systems ( You will not be able to install Safari on Windows )
- Devices ( How to check that your site works on an old iPhone )

All these questions are solved by the tools that we will discuss with you today.

## Browserstack

What is Browserstack? It is cross browser testing tools that help us to test our sites on real devices and operating
systems remotely. From Windows to macOS and iPhone.

<Image src="browserstack.jpg" alt="Browserstack main page UI" />

### Device test

Browserstack allows you to test your site on different devices. To do this, it is enough to select the device and
browser you need and that's it, everything is ready for testing.

<Image src="pixel-pro.jpg" alt="Google Pixel 7 testing screen in Browserstack" />


The screenshot shows that the site is not just running in an emulator, but is a real device (Google Pixel 7Pro) with a
serial number.

> Serial Number - 2B101FDH30XXXX

### Testing with different OS

Remember those green fields on the Windows XP? In just a couple of clicks, you can start a real computer
and test your site without installing Windows ☠️.

<Image src="windows-xp.jpg" alt="shramko.dev website on Windows XP" />

### Multi browser testing

If you want to quickly see how the site looks on many devices and browsers, you can
take [screenshots](https://www.browserstack.com/screenshots) of the pages you want.

<img src="/static/images/screenshots.gif" alt="Animated image with how site can look on browserstack app"/>

Yes, I know that my site does not work on IE. I did it on purpose. [IE 11 Must die](https://death-to-ie11.com/) 👾

### Browserstack developer tools

Sometimes bugs appear in a specific version of a browser or on a device, so you may not only need to look at the site
visually and click on it, but also open the developer tools in the browser and try to find the bug and fix it.

Browserstack can help with this. The DevTools tab opened familiar developer tools such as `Console`, `Network` and
others.

<Image src="dev-tools.jpg" alt="Developer tools" />

At this moment, several options are supported on the mobile phone:

- Safari developer tools
- Chrome developer tools

More on the desktop:

- Firefox developer tools
- Safari developer tools
- Chrome developer tools
- Internet Explorer developer tools

### Local testing

It is also possible to launch not only by URL, but also a local site on localhost.

To do this, you need to update the BrowserStackLocal application and follow
the [instructions](https://www.browserstack.com/docs/live/local-testing).

### Browserstack alternatives

Unfortunately, I've only worked with this tool and don't have the experience to recommend anything else, but you can
always [look at the competitors](https://www.g2.com/products/browserstack/competitors/alternatives) and try it
yourself.

Learn how to test your website across different browsers and devices using BrowserStack. Ensure cross-browser compatibility without maintaining a device lab.

Cross-Browser Compatibility – Testing Guide

Very often, cloud database services such as [neon.tech](https://neon.com/) allow you to connect via URL.
That is, without credentials such as `user`, `password`, etc.

## Connection details

### Connection URL

It's [official PostgreSQL format for connection URLs](https://www.postgresql.org/docs/current/libpq-connect.html#LIBPQ-CONNSTRING)

<Image alt src="postgresql-connection-string.png" priority={true} alt="S.Shramko personal site screenshot"/>

### Base URL and path

Here's an example of a base URL and path structure using uppercase placeholder values:

```text
postgresql://USER:PASSWORD@HOST:PORT/DATABASE
```

<Image alt src="db-table.png" priority={true} alt="S.Shramko personal site screenshot"/>

## How this site connects to the database

### Store your credentials in .env

Store your credentials in your `.env` file.

```shell
PGHOST='<endpoint_hostname>:<port>'
PGDATABASE='<dbname>'
PGUSER='<username>'
PGPASSWORD='<password>'
ENDPOINT_ID='<endpoint_id>'
```

where:

- `endpoint_hostname` the hostname of the branch endpoint. The endpoint hostname has an ep- prefix and appears similar
 to
 this: **ep-tight-salad-272396.us-east-2.aws.neon.tech**
- `dbname` is the name of the database. The default Neon database is neondb
- `user` is the database user
- `password` is the database user's password, which is provided to you when you create a project
- `endpoint_id` is the ID of the branch endpoint that you are connecting to. The endpoint_id has an ep- prefix and
 appears
 similar to this: **ep-tight-salad-272396**

### Use prisma.io to connect Postgres

```js
// You can create DATABASE_URL in your code
const DATABASE_URL = `postgres://${PGUSER}:${PGPASSWORD}@${PGHOST}/${PGDATABASE}`;
```

```shell
# Or better to use .env file
datasource db {
 provider = "postgresql"
 url = env("DATABASE_URL")
 referentialIntegrity = "prisma"
}
```

### Use Datagrip to connect Postgres

You can use same credentials like `HOST`, `PORT`, `USER`, `PASSWORD`, `DATABSE` for connection to Database with
DataGrip.

<Image alt src="db-datagrip.png" priority={true} alt="S.Shramko personal site screenshot"/>

## Related Content

- [Installing PostgreSQL on macOS](/snippets/postgres-install-macos) - step-by-step setup guide
- [SQL Countries Table](/snippets/countries-sql) - ready-to-use seed data for your database

Learn how to connect to PostgreSQL using a connection URL string. Simple guide for Node.js, DataGrip, or any client supporting URL-based database connections.

Use Postgres Connect URLs for DB Connections

<Image alt src="my-site.jpeg" priority={true} alt="S.Shramko personal website screenshot"/>

I'm so excited to announce the launch of my brand-new website!

For over 2 month, I worked on a complete rewrite of shramko.dev. I just want to give you an overview of the technologies
and libraries I used to make this site.

## Overview

Here are the [cloc](https://github.com/AlDanial/cloc) stats:

```shell
cloc --exclude-dir=node_modules .
 358 text files.
 329 unique files. 
 191 files ignored.

T=0.07 s (2903.5 files/s, 389492.6 lines/s)
-------------------------------------------------------------------------------
Language files blank comment code
-------------------------------------------------------------------------------
JavaScript 143 6476 7897 13153
YAML 3 2172 0 8278
Markdown 56 1420 4 4523
TypeScript 86 461 17 4177
XML 12 0 0 1008
JSON 19 0 0 271
CSS 2 40 1 190
diff 1 0 20 23
SVG 1 0 0 17
Prisma Schema 1 2 0 12
INI 1 2 0 11
Bourne Shell 2 2 0 4
Text 2 0 0 4
-------------------------------------------------------------------------------
SUM: 329 10575 7939 31671
-------------------------------------------------------------------------------
```

> Update: Line of Code on <time dateTime="2025-05-16">16 May 2025</time>

The first commit was
in [3 Jul 2022](https://github.com/Shramkoweb/Portfolio/commit/ce017f5e8e55693f85ec7576de8a82c5b7fad835).

## Key features

- Dark and Light Mode
- [Security headers](https://github.com/Shramkoweb/Portfolio/blob/develop/next.config.js#L13) and [CSP](https://github.com/Shramkoweb/Portfolio/blob/develop/next.config.js#L3)
- Feature post with [meta parsing](https://github.com/Shramkoweb/Portfolio/blame/develop/_posts/dirname-error.md#L7)
- Error page with custom 404 page
- Mobile and Responsive styling with Tailwind
- Dynamic Open Graph tags and Twitter cards from [metadata](https://github.com/Shramkoweb/Portfolio/blob/develop/pages/blog/%5Bslug%5D.tsx#L61)
- Accessibility (try to pass [WCAG 2.1 and WCAG 2.2](https://www.w3.org/WAI/standards-guidelines/wcag/))
- Next.js Api for simple express server
- Realtime updates with SWR

## 💻 Technologies

Here are the primary technologies used in this project:

- [React](https://react.dev/): For the UI
- [Next.js](https://nextjs.org/): Framework for hybrid static & server rendering
- [TypeScript](https://www.typescriptlang.org): Typed JavaScript (necessary for any project you plan to maintain)
- [Prisma](https://www.prisma.io): TypeScript ORM with Zero-Cost Type Safety
- [SWR](https://swr.vercel.app/): Cool stale-while-revalidate hook
- [Jest](https://jestjs.io/): JavaScript Testing Framework
- [Testing Library](https://testing-library.com/): Simple and complete testing utilities
- [Tailwind CSS](https://tailwindcss.com): Utility classes for consistent/maintainable styling
- [Postcss](https://postcss.org/): CSS processor (pretty much just use it for autoprefixer and tailwind)
- [next-mdx-remote](https://github.com/hashicorp/next-mdx-remote): Load mdx content for my site (blog posts)
- [gray-matter](https://github.com/jonschlinkert/gray-matter): Smarter YAML front matter parser
- [Postgres](https://www.postgresql.org/): Most Advanced Open Source SQL Database
- [pnpm](https://pnpm.io/): Fast, disk space efficient package manager and i have [post about it](/blog/pnpm)

Here are the services this site uses:

- [Vercel](https://vercel.com): Platform for frontend frameworks and static sites
- [GitHub Actions](https://github.com/features/actions): Hosted CI pipeline service
- [Heroku](https://www.heroku.com/): Reliable and secure PostgreSQL as a service
- [Checkly](https://www.checklyhq.com/): API & E2E monitoring platform
- [Uptimerobot](https://uptimerobot.com/): Uptime monitoring service
- [Snyk](https://snyk.io/): Developer security platform
- [Sentry](https://sentry.io/welcome/): Error reporting service

## 🍭 The new look

Here's how the [latest design](https://shramkoweb.github.io/homepage/) looked before I updated it.

This is a simple <abbr title="HyperText Markup Language">HTML</abbr> and <abbr title="Cascading Style Sheets,">
CSS</abbr> site.
No <abbr title="JavaScript">JS</abbr> and frameworks 😂.

<Image src="old-site.jpg" alt="S.Shramko personal old website screenshot"/>

## 🚀 Deploy

Each commit triggers a build and environment (Production | Preview) creation.
And then we start multiple steps:

> I have post about [ESLint with TypeScript](/blog/eslint-with-typescript) 

- ESLint & TypeScript: Linting the project for simple mistakes and Type checking
- Checkly: Running end-to-end tests
- Vercel: Building and deploy website to production and other environments

Once ESLint, TypeScript, Checkly, and the Build all successfully complete, then we can deploy site.

<Image src="deploy.jpeg" alt="Deploy process screenshot on Vercel"/>

## MDX Compilation

`mdx-bundler` & `next-mdx-remote` allows you to extend [remark](https://github.com/remarkjs/remark)
and [rehype](https://github.com/rehypejs/rehype), providing external plugins to hook into the compilation process.

It helps me to convert a link to an external link and one for wrapping images
with [Next Image](https://nextjs.org/docs/pages/api-reference/components/image).

How does it look:

```tsx
import { serialize } from 'next-mdx-remote/serialize';
import remarkGfm from 'remark-gfm';
import rehypeSlug from 'rehype-slug';
import rehypeCodeTitles from 'rehype-code-titles';
import rehypeAutolinkHeadings from 'rehype-autolink-headings';
import rehypePrism from 'rehype-prism-plus';

export const compileMDX = async (content: string) => serialize(content, {
 mdxOptions: {
 remarkPlugins: [remarkGfm],
 rehypePlugins: [
 rehypeSlug,
 rehypeCodeTitles,
 rehypePrism,
 [
 rehypeAutolinkHeadings,
 {
 properties: {
 className: ['anchor'],
 },
 },
 ],
 ],
 format: 'mdx',
 },
});
```

```tsx
import { MDXComponents } from '@/components/mdx-components';

<div className="w-full mt-4 prose dark:prose-dark max-w-none">
 <MDXRemote {...content} components={MDXComponents} />
</div>
```

## Monitoring with Sentry

Monitoring is an essential part of development.
It’s usually one of the first things you’d want to do after setting up an existing project or getting started with a new
one. Without monitoring, it will be challenging to detect issues in your application or how to resolve them.

> There example of some kind of ["dispatch table" pattern](/blog/dispatch-tables).

```tsx
const { withSentryConfig } = require("@sentry/nextjs");

/** @type {import("next").NextConfig} */
const nextConfig = {
 swcMinify: true,
 experimental: {
 images: {
 allowFutureImage: true,
 },
 browsersListForSwc: true,
 legacyBrowsers: false,
 },
 poweredByHeader: false,
 reactStrictMode: true,
};

// dispatch table pattern
const nextConfigByEnv = {
 production: withSentryConfig(nextConfig, {
 silent: true
 }),
 development: nextConfig
}

module.exports = nextConfigByEnv[process.env.NODE_ENV];
```

## Database and Prisma

[Prisma](https://www.prisma.io/nextjs) makes database access easy. With auto-generated and type-safe queries based on
your database schema, it's easier than ever to manage your data.
Whether you have an existing database or you're starting from scratch, Prisma has you covered.

When combining Prisma with Next.js, you can skip the [CRUD](https://en.wikipedia.org/wiki/Create,_read,_update_and_delete) boilerplate
and directly query the database.
Less code means less bugs.

### Heroku Postgres

Heroku Postgres gives me all the benefits of PostgreSQL without having to spin up and maintain the databases ourselves.
And it is [easy integrate with PhpStorm](https://www.jetbrains.com/help/phpstorm/how-to-connect-to-heroku-postgres.html)
.

### Type Safety

```sql
model
User {
 id String @id @default(cuid())
 email String @unique
 password String
 name String?
}
```

```typescript
type User = {
 id: string
 email: string
 password: string
 name: string | null
}
```

### Querying Data

```typescript
const views = await prisma.views.upsert({
 where: { slug },
 create: {
 slug,
 },
 update: {
 count: {
 increment: 1,
 },
 },
});
```

## Testing

As a developer, you know how important tests are for any production-level project.
Writing tests takes some time, but they will help you in the long run to solve problems in the codebase.

I also [integrate these tests](https://github.com/Shramkoweb/Portfolio/blob/develop/.github/workflows/tests.yml) into
GitHub Actions, so that whenever I deploy to production or make a pull request, tests will run automatically.

My code coverage on <time dateTime="2022-08-28">28 August 2022</time>:

> Update: Test coverage on <time dateTime="2025-05-16">16 May 2025</time>

```shell
------------------------------|---------|----------|---------|---------|-------------------
File | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line #s 
------------------------------|---------|----------|---------|---------|-------------------
All files | 93.45 | 73.33 | 93.61 | 94.4 | 
 components/blog-post-preview | 100 | 50 | 100 | 100 | 
 blog-post-preview.tsx | 100 | 50 | 100 | 100 | 27 
 index.ts | 100 | 100 | 100 | 100 | 
 components/categories | 100 | 100 | 100 | 100 | 
 categories.tsx | 100 | 100 | 100 | 100 | 
 index.ts | 100 | 100 | 100 | 100 | 
 components/footer | 100 | 100 | 100 | 100 | 
 get-copyright.ts | 100 | 100 | 100 | 100 | 
 components/post-reaction | 96.77 | 75 | 100 | 96.66 | 
 index.ts | 100 | 100 | 100 | 100 | 
 post-reaction.tsx | 100 | 100 | 100 | 100 | 
 use-feedback-reducer.ts | 93.33 | 66.66 | 100 | 92.85 | 21 
 components/search-input | 100 | 100 | 100 | 100 | 
 index.ts | 100 | 100 | 100 | 100 | 
 search-input.tsx | 100 | 100 | 100 | 100 | 
 components/view-counter | 100 | 50 | 100 | 100 | 
 index.ts | 100 | 100 | 100 | 100 | 
 view-counter.tsx | 100 | 50 | 100 | 100 | 25 
 lib | 83.33 | 100 | 75 | 100 | 
 fetcher.ts | 100 | 100 | 100 | 100 | 
 ga.ts | 100 | 100 | 100 | 100 | 
 types.ts | 100 | 100 | 100 | 100 | 
 utils.ts | 70 | 100 | 50 | 100 | 
 lib/posts | 96.42 | 100 | 94.73 | 95.45 | 
 api.ts | 94.73 | 100 | 91.66 | 94.28 | 89-90 
 utils.ts | 100 | 100 | 100 | 100 | 
 pages | 100 | 100 | 100 | 100 | 
 404.tsx | 100 | 100 | 100 | 100 | 
 pages/blog | 75 | 50 | 80 | 72.22 | 
 index.tsx | 75 | 50 | 80 | 72.22 | 119-124 
------------------------------|---------|----------|---------|---------|-------------------

Test Suites: 9 passed, 9 total
Tests: 37 passed, 37 total
Snapshots: 0 total
Time: 0.822 s, estimated 1 s
Ran all test suites.
```

> Sometimes I use [Browserstack for cross browsing testing](/blog/cross-browser-testing).

## Next.js

Next's framework allows you to build scalable, performant React code without the configuration hassle.

Quick list of why Next.js has been so good for me:

- Zero Config: Automatic compilation and bundling. Optimized for production from the start
- SSG and SSR: It allows you to render your content in different ways, depending on your application's use case. These
 include pre-rendering with Server-side Rendering or Static Generation, and updating or creating content at runtime
 with Incremental Static Regeneration
- Deploy: You can deploy in a few clicks to [Vercel](https://vercel.com)
- SEO: Automatic Static Optimization & Head Component
- React ecosystem: Wide range of tools and npm packages
- Out of the box support: Through webpack, Next provides developers with out-of-the-box support for asset compilation,
 hot reloading and code splitting, which can further speed up development

<Image src="framework.jpeg" width={400} className="mt-4 mb-8 mx-auto rounded-lg" alt="A meme in which a person tries to choose between two red buttons."/>

> I wrote new article about another framework - Astro [here](/blog/astro) and [here](/blog/linktree) 😆.

## Acknowledgements

- The design was inspired by [Lee Robinson](https://github.com/leerob)

## Conclusion

I can't tell you how much I've learned building this website. 🤓

I'm excited about the new design. And I just had fun doing it. I hope you enjoy it too!

The project is developing and still has many unimplemented features, you can see or suggest
them [here](https://github.com/Shramkoweb/Portfolio/issues).

A deep dive into building my developer portfolio with Next.js, React, and Tailwind CSS. Learn about the tech stack, design decisions, and features.

Presenting the Revamped shramko.dev: Explore the Exciting Updates!


## Intro

Formatting is one of several issues to consider when writing clean code. There are many other things we have to worry
about as well, but formatting is one of those things that we can adjust right away and set the standard for our project.

## ESLint and TSLint

[ESLint](https://eslint.org/) is statically analyzes your code to quickly find problems. It looks at your code, and
tells you when you're not following the standard that you set in place.

## Installation and setup

```shell
npm install --save-dev eslint @typescript-eslint/parser @typescript-eslint/eslint-plugin
```

Next, add the `.eslintrc.json` configuration file to the project root.

```shell
touch .eslintrc
```

In it, use the following start configuration.

```json
{
  "root": true,
  "parser": "@typescript-eslint/parser",
  "plugins": [
    "@typescript-eslint"
  ],
  "extends": [
    "eslint:recommended",
    "plugin:@typescript-eslint/eslint-recommended",
    "plugin:@typescript-eslint/recommended"
  ]
}
```

## Ignoring files we don't want to lint

```shell
touch .eslintignore
```

Then add the things we want to ignore. In the following code sample, we're ignoring the dist/ folder that contains the
compiled TypeScript code.

```ini
node_modules
dist
```

## Adding a script to package

```json
{
  "scripts": {
    "lint": "eslint . --ext .ts"
  }
}
```

Let's run the following command.

```ini
npm run lint
```

## Eslint Rules

ESLint comes with a large number of built-in rules, and you can add more rules through plugins. You can modify which
rules your project uses either using configuration comments or configuration files. To change a rule setting, you must
set the rule ID equal to one of these values:

- "off" or 0 - turn the rule off
- "warn" or 1 - turn the rule on as a warning (doesn’t affect exit code)
- "error" or 2 - turn the rule on as an error (exit code is 1 when triggered)

### Adding a rule

To configure rules inside a configuration file, use the rules key along with an error level and any options you want
to use. For example:

```json
{
  "rules": {
    "curly": "error",
    "quotes": [
      "error",
      "double"
    ]
  }
}
```

Rules are added as keys to this rules attribute, and you can usually find basic eslint rules here on their website in the
[rules' documentation](https://eslint.org/docs/latest/use/configure/rules).

## Conclusion

That's all 🎉.

It's very easy to start using `ESlint`, but its contribution to code formatting and saving time is
huge. Therefore, I recommend always using it.

- [Create-React-App with TypeScript, ESLint, Prettier, and Github Actions](https://brygrill.medium.com/create-react-app-with-typescript-eslint-prettier-and-github-actions-f3ce6a571c97)
- [What is ESLint?](https://hackernoon.com/what-is-eslint-how-do-i-set-it-up-on-atom-70f270f57296)


Step-by-step guide to configuring ESLint with TypeScript. Set up linting rules, integrate with your IDE, and catch errors before they reach production.

Optimizing TypeScript Development with ESLint: A Comprehensive Guide

Set up projects the right way. Learn about linting, formatting, Git hooks, and TypeScript configuration for code quality.

Project Setup10 articles

Articles

Ignore files in Git without adding them to .gitignore

Semantic Versioning in npm

Why Are JavaScript Naming Conventions Important?

Conventional Commits

How to decrease deployment time by 44% with pnpm

How to add SSH keys to your GitHub account

Cross-browser testing

Postgres connect to database with URL

Introducing the new shramko.dev

How to use ESLint with TypeScript