DEV Community: Alexandru Bereghici

Keeping your development resources organized with Notion

Alexandru Bereghici — Mon, 03 Oct 2022 15:39:48 +0000

As a developer, I have a lot of learning resources and I quickly realized that keeping stuff in my browser's bookmark doesn't work for me. I needed a tool to keep everything in one place. I started to use Notion and it didn't disappoint me. In this article I want to share how I structured all my resources using this tool.

Structure

This is what my notion "homepage" looks like. I divided the articles and tutorials into different sections.

Each section is divided into subsections. This allows me to keep the resources related to one topic and it helps me find things faster.

Bookmarks

Each subsection has a database where I store the bookmarks related to this specific topic. I'm using Save to Notion chrome extension to bookmark my links. The benefits of keeping the bookmarks in Notion are that you can add tags or notes, and you can filter or sort them by different criteria.

Task List

The importance of practice in programming cannot be ignored. "Practice makes a man perfect", they said. Often, just reading a tutorial or a book is not enough, you have to get your hands dirty with that specific technology/ pattern/ language/ whatever you learned. In the task list I define small side-projects or things I need to practice. This is a great way to assess the progress.

Reading list

The Reading list is my collection of books. I found that taking notes while reading a book helps me process the information better. Also, I like being able to go back and search my notes and quickly find the most essential information from books I've read.

Saved Tweets

A majority of the most valuable information I consume online comes from tweets and threads. The goal is to keep everything in one place and hopefully there is a bot named Save To Notion that can save the tweets or threads directly in your notion by tagging this bot on a specific tweet.

RSS Feed

I bookmarked many useful blogs, but it was annoying to open each link manually to see if there is new content. A common way to follow the new content is using RSS feeds. Unfortunately, Notion doesn't provide this functionality. I solved this problem by creating a small application with Rust that allows you to manage the RSS sources in a separate notion page and daily reads the new content from your sources and saves them in a notion feed. The project and the setup instructions can be found here:
https://github.com/abereghici/notion-feed.rs

This is how looks the RSS sources:

This is the RSS feed:

Conclusion

Notion is a great and flexible tool that can increase your productivity. It comes with a lot of templates that can cover all your needs. If you find other useful use cases, share them with us in the comments.

Patch an NPM dependency with yarn

Alexandru Bereghici — Mon, 30 May 2022 12:06:20 +0000

When you have a bug in a third party dependency, usually you have a limited set of options to fix it.

You can modify directly the local code of the dependency and make a new build. This works if it's a critical bug and you have to fix it as soon as possible. But, this is not the best option, because you'll lose the fix on the next yarn or npm install. Also, you won't be able to share the fix with your team.

Another option is to fork the package, fix the bug and create a pull request. At this point, you can update your project dependencies and use your fork until the maintainers of the package approve it and publish a new version.

"dependencies": {
  "buggy-package": "your_user/buggy-package#bugfix"
}

This looks like a good option, now your team members will get the fix when they will update the project dependencies. The downside is that you'll have to maintain the fork and make sure it's up to date.

Do we have a better option? Yes, we have. We can use the yarn patch command that was introduced in yarn v2.0.0. This allows you to instantly make and keep fixes to your dependencies without having to fork the packages.

Let's take as an example the remix-run package. During the development I found an issue with the session storage. I opened a pull request to fix it, then I patched the package directly in the project using the command:

  yarn patch @remix-run/node@npm:1.5.1

➤ YN0000: Package @remix-run/node@npm:1.5.1 got extracted with success!
➤ YN0000: You can now edit the following folder: /private/var/folders/xm/qntd4h_97zn6w88tc95bsvxc0000gp/T/xfs-bfc9a229/user
➤ YN0000: Once you are done run yarn patch-commit -s /private/var/folders/xm/qntd4h_97zn6w88tc95bsvxc0000gp/T/xfs-bfc9a229/user and Yarn will store a patchfile based on your changes.
➤ YN0000: Done in 0s 68ms

Once the package is extracted, we can open the created folder and make our changes there. One drawback is that you have to modify the production code, which might be minified and hard to debug. In my case was a simple change to the fileStorage module.

The next step is to commit the patch using the command displayed earlier in the console

yarn patch-commit -s /private/var/folders/xm/qntd4h_97zn6w88tc95bsvxc0000gp/T/xfs-bfc9a229/user

At this point we should see the following change in package.json

"resolutions": {
    "@remix-run/node@1.5.1": "patch:@remix-run/node@npm:1.5.1#.yarn/patches/@remix-run-node-npm-1.5.1-51061cf212.patch"
  }

and in .yarn/patches you'll find the patch file.

The benefits of using this approach are that the patch can be reviewed by your team and it doesn't require additional work to be applied compared to the fork. This should be used for critical fixes, if you need a new feature I would suggest to fork it instead. Also, do not forget to open an issue and create a pull request in the actual package.

Headings & Accessibility

Alexandru Bereghici — Tue, 28 Dec 2021 19:40:07 +0000

Headings are used to organize content in a web page by separating it into meaningful sections. Well-written headings help users to scan quickly through the page and get a sense of whether the page contains the information they are looking for. Headings are critical for accessibility, the adaptive technology users rely on formatted headings to understand and navigate through the page. Without a good heading, the screen reader software read the entire content as a single section.

Generally, it's considered bad practice to skip heading levels, for example having a <h4> without a <h3>. You can not only confuse screen readers but all readers when you don't follow a consistent pattern for your content.

From practice, I've noticed that the developers are using the wrong element just because of style. You should NOT use different heading tags just for styling purposes.

Also, in React it's very easy to end up with a wrong structure, especially when you move components with headings around. You have to check the levels if still make sense and adjust them if needed, so most of the time developers ends up with using only a <h1> element or with a wrong structure.

A very interesting solution for this problem I found in baseweb, a component library created by Uber.

Instead of worrying about what element you have to use, you can have a React Context that handles the document outline algorithm for you. Here is the HeadingLevel component that's used to track the heading levels.

export const HeadingLevel = ({children}: Props) => {
  const level = React.useContext(LevelContext)

  return (
    <LevelContext.Provider value={level + 1}>{children}</LevelContext.Provider>
  )
}

Now the Heading component can consume the level and render the correct element. It contains validations to make sure you cannot have more than 6 levels deep. Also, it solves the styling problem. If you need to have a <h2> element but styled as a <h4>, you can use the styleLevel prop to specify it.

import { LevelContext } from "./heading-level";

interface Props {
  styleLevel?: number;
  children: React.ReactNode;
}

const STYLES = ["", "h1", "h2", "h3", "h4", "h5", "h6"];

const Heading = ({ styleLevel, children }: Props) => {
  const level = React.useContext(LevelContext);

  if (level === 0) {
    throw new Error(
      "Heading component must be a descendant of HeadingLevel component."
    );
  }
  if (level > 6) {
    throw new Error(
      `HeadingLevel cannot be nested ${level} times. The maximum is 6 levels.`
    );
  }

  if (typeof styleLevel !== "undefined" && (styleLevel < 1 || styleLevel > 6)) {
    throw new Error(`styleLevel = ${styleLevel} is out of 1-6 range.`);
  }

  const Element = `h${level}` as React.ElementType;

  const classes = styleLevel ? STYLES[styleLevel] : STYLES[level];

  return <Element className={classes}>{children}</Element>;
};

It might look a bit verbose, but now you don't have to worry about what element you should use, you just care about the levels. If you want to play around with this solution, you can use the sandbox below.

https://codesandbox.io/s/headings-accessibility-cf90z

Cheat Sheets for Web Developers

Alexandru Bereghici — Fri, 24 Dec 2021 17:06:22 +0000

The front-end development evolves with incredible speed. Now it's a challenge to remember all the syntax, methods, or commands of a programming language, framework, or library. Here is where cheat sheets come in. They are great, intuitive resources that help you quickly find what you need.

In this post, I want to share some of the most useful cheat sheets or references I've found it, and I use it daily.

General

https://goalkicker.com/ - Programming Notes for
Professionals books. Includes a lot of frameworks / programming languages.
Probably the best and concise cheat sheets I've found.

https://devdocs.io/ - multiple API documentations in a fast, organized, and searchable interface.

Build a scalable front-end with Rush monorepo and React — VSCode

Alexandru Bereghici — Wed, 17 Nov 2021 17:15:47 +0000

In previous posts, we added prettier and eslint to format our code and enforce a consistent code style across our projects. We can save time by automatically formatting pasted code, or fix lint errors while writing code, without running lint command to see all the errors.

VSCode provides two different types of settings:

User Settings - applied to all VSCode instances
Workspace Settings - applied to the current project only.

We'll use Workspace Settings and few extensions to improve our development experience in VSCode.

Install extensions

Let's add Prettier Formatter for VSCode. Launch VS Code Quick Open (Ctrl+P), paste the following command, and press enter.

ext install esbenp.prettier-vscode

or you can open [https://marketplace.visualstudio.com/items?itemName=esbenp.prettier-vscode (https://marketplace.visualstudio.com/items?itemName=esbenp.prettier-vscode) and install it manually.

In the same manner, let's install VSCode ESLint extension:

ext install dbaeumer.vscode-eslint

or install manually from [https://marketplace.visualstudio.com/items?itemName=dbaeumer.vscode-eslint (https://marketplace.visualstudio.com/items?itemName=dbaeumer.vscode-eslint)

Add settings

Create a new file .vscode/settings.json in the root of our monorepo and let's add the following settings:

{
  "editor.defaultFormatter": "esbenp.prettier-vscode",
  "editor.tabSize": 2,
  "editor.insertSpaces": true,
  "editor.formatOnSave": true,
  "search.exclude": {
    "**/node_modules": true,
    "**/.nyc_output": true,
    "**/.rush": true
  },
  "files.exclude": {
    "**/.nyc_output": true,
    "**/.rush": true,
    "**/*.build.log": true,
    "**/*.build.error.log": true,
    "**/generated-docs": true,
    "**/package-deps.json": true,
    "**/test-apps/**/build": true
  },
  "files.trimTrailingWhitespace": true,
  "eslint.validate": [
    "javascript",
    "javascriptreact",
    "typescript",
    "typescriptreact"
  ],

  "eslint.workingDirectories": [
    {
      "mode": "auto"
    }
  ],
  "eslint.nodePath": "common/temp/node_modules",
  "eslint.trace.server": "verbose",
  "eslint.options": {
    "resolvePluginsRelativeTo": "node_modules/@monorepo/eslint-config"
  },
  "eslint.format.enable": true,
  "eslint.lintTask.enable": true,
  "editor.codeActionsOnSave": {
    "editor.action.fixAll": true,
    "source.fixAll.eslint": true
  }
}

In these settings we:

set Prettier as default formatter
exclude from search some irrelevant folders like node_modules and .nyc_output
exclude from VSCode file explorer irrelevant files
provide a nodePath for ESLint. We're not using eslint directly (we're using lint script from react-scripts) so we're helping the extension to find the eslint binary.
provide a path to eslint plugins. We're helping ESLint extension to pick up the right rules for each project.

I hope you'll find these settings useful.

Build a scalable front-end with Rush monorepo and React — Github Actions + Netlify

Alexandru Bereghici — Wed, 17 Nov 2021 17:15:31 +0000

TL;DR

If you're interested in just see the code, you can find it here:https://github.com/abereghici/rush-monorepo-boilerplate

If you want to see an example with Rush used in a real, large project, you can look atITwin.js, an open-source project developed by Bentley Systems.

Netlify allows you to configure the deployment of your project directly on their dashboard using a build command. This works well when you have a
project in a single repository and you don't need to deploy it very often. They give you a free plan which includes only 300 free build minutes. On the other hand, Github Actions is more flexible and they give you 2000 free build minutes. Also, you can run various tasks like "testing", "linting", "deployment", etc.

Create a Netlify site

Create an account if you don't have one yet on Netlify and create a new site.
Go to the project settings and copy the API ID.
Open Github repository and go to the settings of the repository.
Click on "Secrets" and add a new secret with the name NETLIFY_SITE_ID and paste the copied API ID from Netlify.
Go back to Netlify dashboard and open user settings. https://app.netlify.com/user/applications#personal-access-tokens
Click on "Applications" and create a new access token.
Open Github "Secrets" and create a new secret with the name NETLIFY_AUTH_TOKEN and paste the new access token created on Netlify.

Create Github Actions workflow

At this point, we have all credentials we need for deployment. Now, we can start writing our configurations.

We need to add two more commands in common/rush/command-line.json: lint and test. We'll trigger them on CI/CD before building the project.

In common/rush/command-line.json add the following:

    {
      "name": "test",
      "commandKind": "bulk",
      "summary": "Run tests on each package",
      "description": "Iterates through each package in the monorepo and runs the 'test' script",
      "enableParallelism": true,
      "ignoreMissingScript": true,
      "ignoreDependencyOrder": true,
      "allowWarningsInSuccessfulBuild": true
    },
    {
      "name": "lint",
      "commandKind": "bulk",
      "summary": "Run linter on each package",
      "description": "Iterates through each package in the monorepo and runs the 'lint' script",
      "enableParallelism": true,
      "ignoreMissingScript": true,
      "ignoreDependencyOrder": true,
      "allowWarningsInSuccessfulBuild": false
    }

In the root of monorepo, create a .github/workflows folder and create a new file named main.yml.

mkdir -p .github/workflows

touch .github/workflows/main.yml

Now, let's write the configurations for Github Actions.

# Name of workflow
name: Main workflow

# When workflow is triggered
on:
  push:
    branches:
      - master
  pull_request:
    branches:
      - master
# Jobs to carry out
jobs:
  lint:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: [14.x]
    steps:
      # Get code from repo
      - name: Checkout code
        uses: actions/checkout@v1
      # Install NodeJS
      - name: Use Node.js ${{ matrix.node-version }}
        uses: actions/setup-node@v1
        with:
          node-version: ${{ matrix.node-version }}
      # Run rush install and build on our code
      - name: Install dependencies
        run: |
          node common/scripts/install-run-rush.js change -v
          node common/scripts/install-run-rush.js install
          node common/scripts/install-run-rush.js build
      # Run eslint to check all packages
      - name: Lint packages
        run: node common/scripts/install-run-rush.js lint
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: [14.x]
    env:
      CI: true
    steps:
      # Get code from repo
      - name: Checkout code
        uses: actions/checkout@v1
      # Install NodeJS
      - name: Use Node.js ${{ matrix.node-version }}
        uses: actions/setup-node@v1
        with:
          node-version: ${{ matrix.node-version }}
      # Run rush install
      - name: Install dependencies
        run: |
          node common/scripts/install-run-rush.js change -v
          node common/scripts/install-run-rush.js install
          node common/scripts/install-run-rush.js build
      # Run unit tests for all packages
      - name: Run tests
        run: node common/scripts/install-run-rush.js test
  deploy:
    # Operating system to run job on
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: [14.x]
        app-name: [react-app]
        include:
          - app-name: react-app
            app: '@monorepo/react-app'
            app-dir: 'apps/react-app'
            app-build: 'apps/react-app/build'
            site-id: NETLIFY_SITE_ID
    needs: [lint, test]
    # Steps in job
    steps:
      # Get code from repo
      - name: Checkout code
        uses: actions/checkout@v1
      # Install NodeJS
      - name: Use Node.js ${{ matrix.node-version }}
        uses: actions/setup-node@v1
        with:
          node-version: ${{ matrix.node-version }}
      # Run rush install and build on our code
      - name: Install dependencies
        run: |
          node common/scripts/install-run-rush.js change -v
          node common/scripts/install-run-rush.js install
      - name: Build ${{ matrix.app-name }}
        working-directory: ${{ matrix.app-dir }}
        run: |
          node $GITHUB_WORKSPACE/common/scripts/install-run-rush.js build --verbose --to ${{ matrix.app }}
      - name: Deploy ${{ matrix.app-name }}
        uses: nwtgck/actions-netlify@v1.2
        with:
          publish-dir: ${{ matrix.app-build }}
          production-deploy: ${{ github.event_name != 'pull_request' }}
          github-token: ${{ secrets.GITHUB_TOKEN }}
          enable-pull-request-comment: true
          enable-commit-comment: true
          overwrites-pull-request-comment: true
        env:
          NETLIFY_AUTH_TOKEN: ${{ secrets.NETLIFY_AUTH_TOKEN }}
          NETLIFY_SITE_ID: ${{ secrets[matrix.site-id] }}

Let's break down the configuration above.

We have 3 jobs: lint, test and deploy. lint and test jobs will run in parallel and deploy job will run after both lint and test jobs are successfully done. We're using matrix to run jobs on different NodeJS versions (Currently we're using only 14.x but can be extended to other versions). Matrix is also used to run the same build steps for multiple projects. At the moment, we have only react-app project, but it can be easily extended.

We're running this workflow when the master branch is modified. For pull requests, Netlify will provide preview urls, but if we push something directly to master branch, it will trigger a production build and the code will be deployed to the main url.

The main workflow we created is mostly suitable for development / staging environments. For production, you probably want to trigger the flow manually and create a git tag. You can create another site in Netlify, create a PRODUCTION_NETLIFY_SITE_ID secret in Github
and use the following configuration:

name: React App Production Deployment
on:
  workflow_dispatch:
    inputs:
      version:
        description: Bump Version
        default: v1.0.0
        required: true
      git-ref:
        description: Git Ref (Optional)
        required: false
# Jobs to carry out
jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      # Get code from repo
      - name: Clone Repository (Latest)
        uses: actions/checkout@v2
        if: github.event.inputs.git-ref == ''
      - name: Clone Repository (Custom Ref)
        uses: actions/checkout@v2
        if: github.event.inputs.git-ref != ''
        with:
          ref: ${{ github.event.inputs.git-ref }}
      # Install NodeJS
      - name: Use Node.js 14.x
        uses: actions/setup-node@v1
        with:
          node-version: 14.x
      # Run rush install and build on our code
      - name: Install dependencies
        run: |
          node common/scripts/install-run-rush.js change -v
          node common/scripts/install-run-rush.js install
          node common/scripts/install-run-rush.js build
      # Run eslint to check all packages
      - name: Lint packages
        run: node common/scripts/install-run-rush.js lint
  test:
    runs-on: ubuntu-latest
    env:
      CI: true
    steps:
      # Get code from repo
      - name: Clone Repository (Latest)
        uses: actions/checkout@v2
        if: github.event.inputs.git-ref == ''
      - name: Clone Repository (Custom Ref)
        uses: actions/checkout@v2
        if: github.event.inputs.git-ref != ''
        with:
          ref: ${{ github.event.inputs.git-ref }}
      # Install NodeJS
      - name: Use Node.js 14.x
        uses: actions/setup-node@v1
        with:
          node-version: 14.x
      # Run rush install
      - name: Install dependencies
        run: |
          node common/scripts/install-run-rush.js change -v
          node common/scripts/install-run-rush.js install
          node common/scripts/install-run-rush.js build
      # Run unit tests for all packages
      - name: Run tests
        run: node common/scripts/install-run-rush.js test
  deploy:
    # Operating system to run job on
    runs-on: ubuntu-latest
    needs: [lint, test]
    # Steps in job
    steps:
      # Get code from repo
      - name: Clone Repository (Latest)
        uses: actions/checkout@v2
        if: github.event.inputs.git-ref == ''
      - name: Clone Repository (Custom Ref)
        uses: actions/checkout@v2
        if: github.event.inputs.git-ref != ''
        with:
          ref: ${{ github.event.inputs.git-ref }}
      # Install NodeJS
      - name: Use Node.js 14.x
        uses: actions/setup-node@v1
        with:
          node-version: 14.x
      # Run rush install and build on our code
      - name: Install dependencies
        run: |
          node common/scripts/install-run-rush.js change -v
          node common/scripts/install-run-rush.js install
      # Build app
      - name: Build react app
        working-directory: apps/react-app
        run: |
          node  $GITHUB_WORKSPACE/common/scripts/install-run-rush.js build --verbose --to @monorepo/react-app
      - name: Deploy react app
        uses: nwtgck/actions-netlify@v1.2
        with:
          publish-dir: apps/react-app/build
          production-deploy: true
          github-token: ${{ secrets.GITHUB_TOKEN }}
          enable-pull-request-comment: true
          enable-commit-comment: true
          overwrites-pull-request-comment: true
        env:
          NETLIFY_AUTH_TOKEN: ${{ secrets.NETLIFY_AUTH_TOKEN }}
          NETLIFY_SITE_ID: ${{ secrets.PRODUCTION_NETLIFY_SITE_ID }}
      # Create release tag
      - name: Create tag
        run: |
          git tag ${{ github.event.inputs.version }}
          git push origin --tags

Now we can trigger a production deploy manually for react-app project. We can provide the next version number as a version parameter and it will create a tag for us. If we want to revert to a previous version, you can also do it by providing a git-ref.

If you encountered any issues during the process, you can see the code related to this post here.

Build a scalable front-end with Rush monorepo and React — ESLint + Lint Staged

Alexandru Bereghici — Wed, 17 Nov 2021 17:15:12 +0000

TL;DR

If you're interested in just see the code, you can find it here: https://github.com/abereghici/rush-monorepo-boilerplate

If you want to see an example with Rush used in a real, large project, you can look at [ITwin.js(https://github.com/imodeljs/imodeljs), an open-source project developed by Bentley Systems.

ESLint is a dominant tool for linting TypeScript and JavaScript code. We'll use it together with Lint Staged to achieve the goal "Enforced rules for code quality" we defined in Part 1.

ESLint works with a set of rules you define. If you already have a configuration for ESLint that you like, you can add it in our next setup. We'll be using AirBnB’s ESLint config, which is the most common rules list for JavaScript projects. As of mid-2021, it gets over 2.7 million downloads per week from NPM.

Build eslint-config package

Let's start by creating a folder named eslint-config in packages and creating package.json file.

mkdir packages/eslint-config

touch packages/eslint-config/package.json

Paste the following content to packages/eslint-config/package.json:

{
  "name": "@monorepo/eslint-config",
  "version": "1.0.0",
  "description": "Shared eslint rules",
  "main": "index.js",
  "scripts": {
    "build": ""
  },
  "dependencies": {
    "@babel/eslint-parser": "~7.14.4",
    "@babel/eslint-plugin": "~7.13.16",
    "@babel/preset-react": "~7.13.13",
    "@typescript-eslint/eslint-plugin": "^4.26.1",
    "@typescript-eslint/parser": "^4.26.1",
    "babel-eslint": "~10.1.0",
    "eslint-config-airbnb": "^18.2.1",
    "eslint-config-prettier": "^7.1.0",
    "eslint-config-react-app": "~6.0.0",
    "eslint-plugin-import": "^2.23.4",
    "eslint-plugin-flowtype": "^5.2.1",
    "eslint-plugin-jest": "^24.1.5",
    "eslint-plugin-jsx-a11y": "^6.4.1",
    "eslint-plugin-prettier": "^3.3.1",
    "eslint-plugin-react": "^7.24.0",
    "eslint-plugin-react-hooks": "^4.2.0",
    "eslint-plugin-testing-library": "^3.9.2"
  },
  "devDependencies": {
    "read-pkg-up": "7.0.1",
    "semver": "~7.3.5"
  },
  "peerDependencies": {
    "eslint": "^7.28.0",
    "typescript": "^4.3.5"
  },
  "peerDependenciesMeta": {
    "typescript": {
      "optional": true
    }
  }
}

Here we added all dependencies we need for our ESLint config.

Now, let's create a config.js file where we'll define ESLint configurations, non-related to rules.

const fs = require('fs');
const path = require('path');

const tsConfig = fs.existsSync('tsconfig.json')
  ? path.resolve('tsconfig.json')
  : undefined;

module.exports = {
  parser: '@babel/eslint-parser',
  parserOptions: {
    babelOptions: {
      presets: ['@babel/preset-react'],
    },
    requireConfigFile: false,
    ecmaVersion: 2021,
    sourceType: 'module',
    ecmaFeatures: {
      jsx: true,
    },
  },
  env: {
    es6: true,
    jest: true,
    browser: true,
  },
  globals: {
    globals: true,
    shallow: true,
    render: true,
    mount: true,
  },
  overrides: [
    {
      files: ['**/*.ts?(x)'],
      parser: '@typescript-eslint/parser',
      parserOptions: {
        ecmaVersion: 2021,
        sourceType: 'module',
        project: tsConfig,
        ecmaFeatures: {
          jsx: true,
        },
        warnOnUnsupportedTypeScriptVersion: true,
      },
    },
  ],
};

We'll split ESLint rules in multiple files. In base.js file we'll define the main rules that can be applied to all packages. In react.js will be the React-specific rules.
We might have packages that doesn't use React, so we'll use only the base rules.

Create a base.js file and add:

module.exports = {
  extends: ['airbnb', 'prettier'],
  plugins: ['prettier'],
  rules: {
    camelcase: 'error',
    semi: ['error', 'always'],
    quotes: [
      'error',
      'single',
      {
        allowTemplateLiterals: true,
        avoidEscape: true,
      },
    ],
  },
  overrides: [
    {
      files: ['**/*.ts?(x)'],
      extends: [
        'prettier/@typescript-eslint',
        'plugin:@typescript-eslint/recommended',
      ],
      rules: {},
    },
  ],
};

Here we're extending airbnb and prettier configurations. Here you can include other base rules you would like to use.

In react.js add the following:

const readPkgUp = require('read-pkg-up');
const semver = require('semver');

let oldestSupportedReactVersion = '17.0.1';

// Get react version from package.json and used it in lint configuration
try {
  const pkg = readPkgUp.sync({ normalize: true });
  const allDeps = Object.assign(
    { react: '17.0.1' },
    pkg.peerDependencies,
    pkg.devDependencies,
    pkg.dependencies
  );

  oldestSupportedReactVersion = semver
    .validRange(allDeps.react)
    .replace(/[>=<|]/g, ' ')
    .split(' ')
    .filter(Boolean)
    .sort(semver.compare)[0];
} catch (error) {
  // ignore error
}

module.exports = {
  extends: [
    'react-app',
    'react-app/jest',
    'prettier/react',
    'plugin:testing-library/recommended',
    'plugin:testing-library/react',
  ],
  plugins: ['react', 'react-hooks', 'testing-library', 'prettier'],
  settings: {
    react: {
      version: oldestSupportedReactVersion,
    },
  },
  rules: {
    'react/jsx-fragments': ['error', 'element'],
    'react-hooks/rules-of-hooks': 'error',
  },
  overrides: [
    {
      files: ['**/*.ts?(x)'],
      rules: {
        'react/jsx-filename-extension': [
          1,
          {
            extensions: ['.js', '.jsx', '.ts', '.tsx'],
          },
        ],
      },
    },
  ],
};

We have to provide a react version to react-app configuration. Instead of hardcoding it we'll use read-pkg-up to get the version from package.json. semver is used to help us picking the right version.

Last step is to define the entry-point of our configurations. Create a index.js file and add:

module.exports = {
  extends: ['./config.js', './base.js'],
};

Add lint command to react-scripts

ESLint can be used in a variety of ways. You can install it on every package or create a lint script that runs ESLint bin for you. I'm feeling more comfortable with the second approach. We can control the ESLint version in one place which makes the upgrade process easier.

We'll need few util functions for lint script, so create an index.js file inside of
packages/react-scripts/scripts/utils and add the following:

const fs = require('fs');
const path = require('path');
const which = require('which');
const readPkgUp = require('read-pkg-up');

const { path: pkgPath } = readPkgUp.sync({
  cwd: fs.realpathSync(process.cwd()),
});

const appDirectory = path.dirname(pkgPath);

const fromRoot = (...p) => path.join(appDirectory, ...p);

function resolveBin(
  modName,
  { executable = modName, cwd = process.cwd() } = {}
) {
  let pathFromWhich;
  try {
    pathFromWhich = fs.realpathSync(which.sync(executable));
    if (pathFromWhich && pathFromWhich.includes('.CMD')) return pathFromWhich;
  } catch (_error) {
    // ignore _error
  }
  try {
    const modPkgPath = require.resolve(`${modName}/package.json`);
    const modPkgDir = path.dirname(modPkgPath);
    const { bin } = require(modPkgPath);
    const binPath = typeof bin === 'string' ? bin : bin[executable];
    const fullPathToBin = path.join(modPkgDir, binPath);
    if (fullPathToBin === pathFromWhich) {
      return executable;
    }
    return fullPathToBin.replace(cwd, '.');
  } catch (error) {
    if (pathFromWhich) {
      return executable;
    }
    throw error;
  }
}

module.exports = {
  resolveBin,
  fromRoot,
  appDirectory,
};

The most important function here is resolveBin that will try to resolve the binary for a given module.

Create lint.js file inside of packages/react-scripts/scripts and add the following:

const spawn = require('react-dev-utils/crossSpawn');
const yargsParser = require('yargs-parser');
const { resolveBin, fromRoot, appDirectory } = require('./utils');

let args = process.argv.slice(2);
const parsedArgs = yargsParser(args);

const cache = args.includes('--no-cache')
  ? []
  : [
      '--cache',
      '--cache-location',
      fromRoot('node_modules/.cache/.eslintcache'),
    ];

const files = parsedArgs._;

const relativeEslintNodeModules = 'node_modules/@monorepo/eslint-config';
const pluginsDirectory = `${appDirectory}/${relativeEslintNodeModules}`;

const resolvePluginsRelativeTo = [
  '--resolve-plugins-relative-to',
  pluginsDirectory,
];

const result = spawn.sync(
  resolveBin('eslint'),
  [
    ...cache,
    ...files,
    ...resolvePluginsRelativeTo,
    '--no-error-on-unmatched-pattern',
  ],
  { stdio: 'inherit' }
);

process.exit(result.status);

In packages/react-scripts/bin/react-scripts.js register the lint command:

 . . .
 const scriptIndex = args.findIndex(
  x => x === 'build' || x === 'start' || x === 'lint' || x === 'test'
);
. . .

. . .
if (['build', 'start', 'lint', 'test'].includes(script)) {
. . .

Now, add our new dependencies in packages/react-scripts/package.json:

. . .
    "which": "~2.0.2",
    "read-pkg-up": "7.0.1",
    "yargs-parser": "~20.2.7",
    "eslint": "^7.28.0"
. . .

Lint script in action

Our lint script is ready, now let's run it in react-app project.

Create a new file named .eslintrc.js and add the following:

module.exports = {
  extends: ['@monorepo/eslint-config', '@monorepo/eslint-config/react'],
};

Inside package.json add eslint-config as dependency:

. . .
 "@monorepo/eslint-config": "1.0.0"
 . . .

In scripts section add lint command:

...
"lint": "react-scripts lint src"
...

Run rush update following by rushx lint. At this point you should see a bunch of ESLint errors. As an exercise, you can try to fix them by enabling / disabling some rules in eslint-config or modify react-app project to make it pass the linting.

Add lint-staged command to react-scripts

We'll follow the same approach as we did with lint script. Create lint-staged.js file inside of packages/react-scripts/scripts and add the following:

const spawn = require('react-dev-utils/crossSpawn');
const { resolveBin } = require('./utils');

const args = process.argv.slice(2);

result = spawn.sync(resolveBin('lint-staged'), [...args], {
  stdio: 'inherit',
});

process.exit(result.status);

Add lint-staged as dependency in package.json:

...
 "lint-staged": "~11.0.0"
...

Open packages/react-scripts/bin/react-scripts.js and register lint-staged command.

Next step is to register a lint-staged rush command in common/config/command-line.json, as we did with prettier command in Part 1.

{
  "name": "lint-staged",
  "commandKind": "bulk",
  "summary": "Run lint-staged on each package",
  "description": "Iterates through each package in the monorepo and runs the 'lint-staged' script",
  "enableParallelism": false,
  "ignoreMissingScript": true,
  "ignoreDependencyOrder": true,
  "allowWarningsInSuccessfulBuild": true
},

Now, let's run lint-staged command on git pre-commit hook. Open common/git-hooks/pre-commit and add the append to the end of the file:

node common/scripts/install-run-rush.js lint-staged || exit $?

Lint staged in action

Let's define what tasks we want lint-staged to run for react-app project.
Open package.json of react-app and add the configuration for lint-staged:

  "lint-staged": {
    "src/**/*.{ts,tsx}": [
      "react-scripts lint --fix --",
      "react-scripts test --findRelatedTests --watchAll=false --silent"
    ],
  },

Also in package.json add the new lint-staged script:

"lint-staged": "react-scripts lint-staged"

Now, on each commit lint-staged will lint our files and will run tests for related files.

Run rush install to register our command, then rush update and let's commit our changes to see everything in action.

If you encountered any issues during the process, you can see the code related to this post here.

Build a scalable front-end with Rush monorepo and React — Webpack + Jest

Alexandru Bereghici — Wed, 17 Nov 2021 17:14:54 +0000

TL;DR

If you're interested in just see the code, you can find it here: https://github.com/abereghici/rush-monorepo-boilerplate

If you want to see an example with Rush used in a real, large project, you can look at ITwin.js, an open-source project developed by Bentley Systems.

create-react-app is a great tool that allows you to develop react applications without having to manually configure build tools.
When you develop small projects, it might be overkill to manage your own build tools and CRA is more than enough, but when you start to build large projects you might find CRA configuration lacking. CRA is an opinionated pre-configured tool, so there will always be some settings that you aren't happy with and you cannot change them.

In this post, we'll create our own build tools, based on create-react-app.
This will give us full control over the build process.

Create react-scripts package

Let's create a new folder for react-scripts package.

mkdir -p packages/react-scripts

Create a package.json file inside the react-scripts folder and add the following configuration:

{
  "name": "@monorepo/react-scripts",
  "version": "1.0.0",
  "files": ["bin", "config", "lib", "scripts", "utils"],
  "bin": {
    "react-scripts": "./bin/react-scripts.js"
  },
  "types": "./lib/react-app.d.ts",
  "dependencies": {
    "@babel/core": "7.12.3",
    "@pmmmwh/react-refresh-webpack-plugin": "0.4.3",
    "@svgr/webpack": "5.5.0",
    "@testing-library/jest-dom": "^5.14.1",
    "@testing-library/react": "^11.2.7",
    "@testing-library/user-event": "^12.8.3",
    "@types/jest": "^26.0.24",
    "@types/node": "^12.20.19",
    "@types/react": "^17.0.18",
    "@types/react-dom": "^17.0.9",
    "@typescript-eslint/eslint-plugin": "^4.5.0",
    "@typescript-eslint/parser": "^4.5.0",
    "babel-eslint": "^10.1.0",
    "babel-jest": "^26.6.0",
    "babel-loader": "8.1.0",
    "babel-plugin-named-asset-import": "^0.3.7",
    "babel-preset-react-app": "^10.0.0",
    "bfj": "^7.0.2",
    "camelcase": "^6.1.0",
    "case-sensitive-paths-webpack-plugin": "2.3.0",
    "css-loader": "4.3.0",
    "dotenv": "8.2.0",
    "dotenv-expand": "5.1.0",
    "file-loader": "6.1.1",
    "fs-extra": "^9.0.1",
    "html-webpack-plugin": "4.5.0",
    "identity-obj-proxy": "3.0.0",
    "jest": "26.6.0",
    "jest-circus": "26.6.0",
    "jest-resolve": "26.6.0",
    "jest-watch-typeahead": "0.6.1",
    "mini-css-extract-plugin": "0.11.3",
    "optimize-css-assets-webpack-plugin": "5.0.4",
    "pnp-webpack-plugin": "1.6.4",
    "postcss-flexbugs-fixes": "4.2.1",
    "postcss-loader": "3.0.0",
    "postcss-normalize": "8.0.1",
    "postcss-preset-env": "6.7.0",
    "postcss-safe-parser": "5.0.2",
    "prompts": "2.4.0",
    "react-app-polyfill": "^2.0.0",
    "react-dev-utils": "^11.0.3",
    "react-refresh": "^0.8.3",
    "resolve": "1.18.1",
    "resolve-url-loader": "^3.1.2",
    "sass-loader": "^10.0.5",
    "semver": "7.3.2",
    "style-loader": "1.3.0",
    "terser-webpack-plugin": "4.2.3",
    "ts-pnp": "1.2.0",
    "url-loader": "4.1.1",
    "web-vitals": "^1.1.2",
    "webpack": "4.44.2",
    "webpack-dev-server": "3.11.1",
    "webpack-manifest-plugin": "2.2.0",
    "workbox-webpack-plugin": "5.1.4"
  },
  "devDependencies": {
    "react": "^17.0.1",
    "react-dom": "^17.0.1"
  }
}

As you already noticed, we moved all build dependencies from react-app project to react-scripts package.

Move config and scripts folders from react-app to react-scripts and let's adjust the configurations.

Remove ESLint plugin and its dependencies from packages/react-scripts/config/webpack.config.js. We'll use it later as a separate action in our build process.

Open packages/react-scripts/config/paths.js and replace the file content with:

const path = require('path');
const fs = require('fs');
const getPublicUrlOrPath = require('react-dev-utils/getPublicUrlOrPath');

// Make sure any symlinks in the project folder are resolved:
// https://github.com/facebook/create-react-app/issues/637
const appDirectory = fs.realpathSync(process.cwd());
const resolveApp = relativePath => path.resolve(appDirectory, relativePath);

// We use `PUBLIC_URL` environment variable or "homepage" field to infer
// "public path" at which the app is served.
// webpack needs to know it to put the right <script> hrefs into HTML even in
// single-page apps that may serve index.html for nested URLs like /todos/42.
// We can't use a relative path in HTML because we don't want to load something
// like /todos/42/static/js/bundle.7289d.js. We have to know the root.
const publicUrlOrPath = getPublicUrlOrPath(
  process.env.NODE_ENV === 'development',
  require(resolveApp('package.json')).homepage,
  process.env.PUBLIC_URL
);

const buildPath = process.env.BUILD_PATH || 'build';

const moduleFileExtensions = [
  'web.mjs',
  'mjs',
  'web.js',
  'js',
  'web.ts',
  'ts',
  'web.tsx',
  'tsx',
  'json',
  'web.jsx',
  'jsx',
];

// Resolve file paths in the same order as webpack
const resolveModule = (resolveFn, filePath) => {
  const extension = moduleFileExtensions.find(extension =>
    fs.existsSync(resolveFn(`${filePath}.${extension}`))
  );

  if (extension) {
    return resolveFn(`${filePath}.${extension}`);
  }

  return resolveFn(`${filePath}.js`);
};

const resolveOwn = relativePath => path.resolve(__dirname, '..', relativePath);

module.exports = {
  dotenv: resolveApp('.env'),
  appPath: resolveApp('.'),
  appBuild: resolveApp(buildPath),
  appPublic: resolveApp('public'),
  appHtml: resolveApp('public/index.html'),
  appIndexJs: resolveModule(resolveApp, 'src/index'),
  appPackageJson: resolveApp('package.json'),
  appSrc: resolveApp('src'),
  appTsConfig: resolveApp('tsconfig.json'),
  appJsConfig: resolveApp('jsconfig.json'),
  yarnLockFile: resolveApp('yarn.lock'),
  testsSetup: resolveModule(resolveApp, 'src/setupTests'),
  proxySetup: resolveApp('src/setupProxy.js'),
  appNodeModules: resolveApp('node_modules'),
  appWebpackCache: resolveApp('node_modules/.cache'),
  appTsBuildInfoFile: resolveApp('node_modules/.cache/tsconfig.tsbuildinfo'),
  swSrc: resolveModule(resolveApp, 'src/service-worker'),
  publicUrlOrPath,
  // These properties only exist before ejecting:
  ownPath: resolveOwn('.'),
  ownNodeModules: resolveOwn('node_modules'), // This is empty on npm 3
  appTypeDeclarations: resolveApp('src/react-app-env.d.ts'),
  ownTypeDeclarations: resolveOwn('lib/react-app.d.ts'),
};

module.exports.moduleFileExtensions = moduleFileExtensions;

The most important change in this file is the resolveApp function call.
We shouldn't use relative paths anymore, because we are moving the configuration files to react-scripts package.
We'll get the project files paths using a combination between path.resolve and process.cwd().

Create a bin folder and in react-scripts.js file add the following code:

process.on('unhandledRejection', err => {
  throw err;
});

const spawn = require('react-dev-utils/crossSpawn');
const args = process.argv.slice(2);

const scriptIndex = args.findIndex(
  x => x === 'build' || x === 'start' || x === 'test'
);
const script = scriptIndex === -1 ? args[0] : args[scriptIndex];
const nodeArgs = scriptIndex > 0 ? args.slice(0, scriptIndex) : [];

if (['build', 'start', 'test'].includes(script)) {
  const result = spawn.sync(
    process.execPath,
    nodeArgs
      .concat(require.resolve('../scripts/' + script))
      .concat(args.slice(scriptIndex + 1)),
    { stdio: 'inherit' }
  );
  if (result.signal) {
    if (result.signal === 'SIGKILL') {
      console.log(
        'The build failed because the process exited too early. ' +
          'This probably means the system ran out of memory or someone called ' +
          '`kill -9` on the process.'
      );
    } else if (result.signal === 'SIGTERM') {
      console.log(
        'The build failed because the process exited too early. ' +
          'Someone might have called `kill` or `killall`, or the system could ' +
          'be shutting down.'
      );
    }
    process.exit(1);
  }
  process.exit(result.status);
} else {
  console.log('Unknown script "' + script + '".');
}

This will be the entry-point of our CLI. Every time when you'll want to add a new command you have to adjust this file.

Create another folder named lib and in react-app.d.ts file add the following code:

/// <reference types="node" />
/// <reference types="react" />
/// <reference types="react-dom" />

declare namespace NodeJS {
  interface ProcessEnv {
    readonly NODE_ENV: 'development' | 'production' | 'test';
    readonly PUBLIC_URL: string;
  }
}

declare module '*.avif' {
  const src: string;
  export default src;
}

declare module '*.bmp' {
  const src: string;
  export default src;
}

declare module '*.gif' {
  const src: string;
  export default src;
}

declare module '*.jpg' {
  const src: string;
  export default src;
}

declare module '*.jpeg' {
  const src: string;
  export default src;
}

declare module '*.png' {
  const src: string;
  export default src;
}

declare module '*.webp' {
  const src: string;
  export default src;
}

declare module '*.svg' {
  import * as React from 'react';

  export const ReactComponent: React.FunctionComponent<
    React.SVGProps<SVGSVGElement> & { title?: string }
  >;

  const src: string;
  export default src;
}

declare module '*.module.css' {
  const classes: { readonly [key: string]: string };
  export default classes;
}

declare module '*.module.scss' {
  const classes: { readonly [key: string]: string };
  export default classes;
}

declare module '*.module.sass' {
  const classes: { readonly [key: string]: string };
  export default classes;
}

Here we'll store all type definitions for css, sass, scss and image files and we'll reuse in all react applications inside of the monorepo. You can address to these type definitions by creating a file in your react project named react-app-env.d.ts with the following content:

/// <reference types="@monorepo/react-scripts" />

Now let's register @monorepo/react-scripts package in rush configuration file. Open rush.json file and add an entry like this under the projects inventory:

. . .
 "projects": [
    {
      "packageName": "@monorepo/react-scripts",
      "projectFolder": "packages/react-scripts",
      "reviewCategory": "tools"
    }
  ]
. . .

Now, let's cleanup apps/react-app/package-json file by removing all dependencies related to build tools. We'll also remove the configurations for eslint, babel or jest, because we'll store them in a separate files. In our dependencies we'll list @monorepo/react-scripts package.

Edit apps/react-app/package.json file and add the following configuration:

{
  "name": "@monorepo/react-app",
  "version": "0.1.0",
  "private": true,
  "dependencies": {
    "@testing-library/jest-dom": "^5.14.1",
    "@testing-library/react": "^11.2.7",
    "@testing-library/user-event": "^12.8.3",
    "@types/jest": "^26.0.24",
    "@types/react": "^17.0.18",
    "@types/react-dom": "^17.0.9",
    "react": "^17.0.2",
    "react-dom": "^17.0.2",
    "typescript": "^4.3.5",
    "web-vitals": "^1.1.2",
    "@monorepo/react-scripts": "1.0.0"
  },
  "scripts": {
    "start": "react-scripts start",
    "build": "react-scripts build",
    "test": "react-scripts test"
  }
}

Run rush update to install all dependencies and let's try to build our app with the react-script package we just created.

cd apps/react-app

rushx build

Setup BrowserList

By default, react-scripts expect to find a browserslist configuration in each project, otherwise, it fallbacks to the default browserslist configuration. If you want to use the same configuration for all your projects, you can modify packages/react-scripts/build.js to use browserslist from package.json from @monorepo/react-scripts.

Open package.json from @monorepo/react-scripts and add the following configuration:

"browserslist": {
    "production": [
      ">0.2%",
      "not dead",
      "not op_mini all"
    ],
    "development": [
      "last 1 chrome version",
      "last 1 firefox version",
      "last 1 safari version"
    ]
  },

Modify the checkBrowsers function call from packages/react-scripts/build.js and packages/react-scripts/start.js with:

checkBrowsers(paths.ownPath, isInteractive)

Setup Jest

Our current test script expects to find a jest configuration in each project. We'll modify it to use a shared configuration.

Create a utils folder in packages/react-scripts/scripts and in createJestConfig.js file add the following:

const fs = require('fs');
const chalk = require('react-dev-utils/chalk');
const paths = require('../../config/paths');
const modules = require('../../config/modules');

module.exports = (resolve, rootDir, isEjecting) => {
  // Use this instead of `paths.testsSetup` to avoid putting
  // an absolute filename into configuration after ejecting.
  const setupTestsMatches = paths.testsSetup.match(/src[/\\]setupTests\.(.+)/);
  const setupTestsFileExtension =
    (setupTestsMatches && setupTestsMatches[1]) || 'js';
  const setupTestsFile = fs.existsSync(paths.testsSetup)
    ? `<rootDir>/src/setupTests.${setupTestsFileExtension}`
    : undefined;

  const config = {
    roots: ['<rootDir>/src'],

    collectCoverageFrom: ['src/**/*.{js,jsx,ts,tsx}', '!src/**/*.d.ts'],

    setupFiles: [
      isEjecting
        ? 'react-app-polyfill/jsdom'
        : require.resolve('react-app-polyfill/jsdom'),
    ],

    setupFilesAfterEnv: setupTestsFile ? [setupTestsFile] : [],
    testMatch: [
      '<rootDir>/src/**/__tests__/**/*.{js,jsx,ts,tsx}',
      '<rootDir>/src/**/*.{spec,test}.{js,jsx,ts,tsx}',
    ],
    testEnvironment: 'jsdom',
    testRunner: require.resolve('jest-circus/runner'),
    transform: {
      '^.+\\.(js|jsx|mjs|cjs|ts|tsx)$': resolve(
        'config/jest/babelTransform.js'
      ),
      '^.+\\.css$': resolve('config/jest/cssTransform.js'),
      '^(?!.*\\.(js|jsx|mjs|cjs|ts|tsx|css|json)$)': resolve(
        'config/jest/fileTransform.js'
      ),
    },
    transformIgnorePatterns: [
      '[/\\\\]node_modules[/\\\\].+\\.(js|jsx|mjs|cjs|ts|tsx)$',
      '^.+\\.module\\.(css|sass|scss)$',
    ],
    modulePaths: modules.additionalModulePaths || [],
    moduleNameMapper: {
      '^react-native$': 'react-native-web',
      '^.+\\.module\\.(css|sass|scss)$': 'identity-obj-proxy',
      ...(modules.jestAliases || {}),
    },
    moduleFileExtensions: [...paths.moduleFileExtensions, 'node'].filter(
      ext => !ext.includes('mjs')
    ),
    watchPlugins: [
      'jest-watch-typeahead/filename',
      'jest-watch-typeahead/testname',
    ],
    resetMocks: true,
  };
  if (rootDir) {
    config.rootDir = rootDir;
  }
  const overrides = Object.assign({}, require(paths.appPackageJson).jest);
  const supportedKeys = [
    'clearMocks',
    'collectCoverageFrom',
    'coveragePathIgnorePatterns',
    'coverageReporters',
    'coverageThreshold',
    'displayName',
    'extraGlobals',
    'globalSetup',
    'globalTeardown',
    'moduleNameMapper',
    'resetMocks',
    'resetModules',
    'restoreMocks',
    'snapshotSerializers',
    'testMatch',
    'transform',
    'transformIgnorePatterns',
    'watchPathIgnorePatterns',
  ];
  if (overrides) {
    supportedKeys.forEach(key => {
      if (Object.prototype.hasOwnProperty.call(overrides, key)) {
        if (Array.isArray(config[key]) || typeof config[key] !== 'object') {
          // for arrays or primitive types, directly override the config key
          config[key] = overrides[key];
        } else {
          // for object types, extend gracefully
          config[key] = Object.assign({}, config[key], overrides[key]);
        }

        delete overrides[key];
      }
    });
    const unsupportedKeys = Object.keys(overrides);
    if (unsupportedKeys.length) {
      const isOverridingSetupFile =
        unsupportedKeys.indexOf('setupFilesAfterEnv') > -1;

      if (isOverridingSetupFile) {
        console.error(
          chalk.red(
            'We detected ' +
              chalk.bold('setupFilesAfterEnv') +
              ' in your package.json.\n\n' +
              'Remove it from Jest configuration, and put the initialization code in ' +
              chalk.bold('src/setupTests.js') +
              '.\nThis file will be loaded automatically.\n'
          )
        );
      } else {
        console.error(
          chalk.red(
            '\nOut of the box, Create React App only supports overriding ' +
              'these Jest options:\n\n' +
              supportedKeys
                .map(key => chalk.bold('  \u2022 ' + key))
                .join('\n') +
              '.\n\n' +
              'These options in your package.json Jest configuration ' +
              'are not currently supported by Create React App:\n\n' +
              unsupportedKeys
                .map(key => chalk.bold('  \u2022 ' + key))
                .join('\n') +
              '\n\nIf you wish to override other Jest options, you need to ' +
              'eject from the default setup. You can do so by running ' +
              chalk.bold('npm run eject') +
              ' but remember that this is a one-way operation. ' +
              'You may also file an issue with Create React App to discuss ' +
              'supporting more options out of the box.\n'
          )
        );
      }

      process.exit(1);
    }
  }
  return config;
};

Now let's use this configuration. Modify the test script in packages/react-scripts/scripts/test.js to look like this:

// Do this as the first thing so that any code reading it knows the right env.
process.env.BABEL_ENV = 'test';
process.env.NODE_ENV = 'test';
process.env.PUBLIC_URL = '';

process.on('unhandledRejection', err => {
  throw err;
});

// Ensure environment variables are read.
require('../config/env');

const jest = require('jest');
const execSync = require('child_process').execSync;
let argv = process.argv.slice(2);

function isInGitRepository() {
  try {
    execSync('git rev-parse --is-inside-work-tree', { stdio: 'ignore' });
    return true;
  } catch (e) {
    return false;
  }
}

function isInMercurialRepository() {
  try {
    execSync('hg --cwd . root', { stdio: 'ignore' });
    return true;
  } catch (e) {
    return false;
  }
}

// Watch unless on CI or explicitly running all tests
if (
  !process.env.CI &&
  argv.indexOf('--watchAll') === -1 &&
  argv.indexOf('--watchAll=false') === -1
) {
  // https://github.com/facebook/create-react-app/issues/5210
  const hasSourceControl = isInGitRepository() || isInMercurialRepository();
  argv.push(hasSourceControl ? '--watch' : '--watchAll');
}

const createJestConfig = require('./utils/createJestConfig');
const path = require('path');
const paths = require('../config/paths');
argv.push(
  '--config',
  JSON.stringify(
    createJestConfig(
      relativePath => path.resolve(__dirname, '..', relativePath),
      path.resolve(paths.appSrc, '..'),
      false
    )
  )
);

// This is a very dirty workaround for https://github.com/facebook/jest/issues/5913.
// We're trying to resolve the environment ourselves because Jest does it incorrectly.
// TODO: remove this as soon as it's fixed in Jest.
const resolve = require('resolve');
function resolveJestDefaultEnvironment(name) {
  const jestDir = path.dirname(
    resolve.sync('jest', {
      basedir: __dirname,
    })
  );
  const jestCLIDir = path.dirname(
    resolve.sync('jest-cli', {
      basedir: jestDir,
    })
  );
  const jestConfigDir = path.dirname(
    resolve.sync('jest-config', {
      basedir: jestCLIDir,
    })
  );
  return resolve.sync(name, {
    basedir: jestConfigDir,
  });
}
let cleanArgv = [];
let env = 'jsdom';
let next;
do {
  next = argv.shift();
  if (next === '--env') {
    env = argv.shift();
  } else if (next.indexOf('--env=') === 0) {
    env = next.substring('--env='.length);
  } else {
    cleanArgv.push(next);
  }
} while (argv.length > 0);
argv = cleanArgv;
let resolvedEnv;
try {
  resolvedEnv = resolveJestDefaultEnvironment(`jest-environment-${env}`);
} catch (e) {
  // ignore
}
if (!resolvedEnv) {
  try {
    resolvedEnv = resolveJestDefaultEnvironment(env);
  } catch (e) {
    // ignore
  }
}
const testEnvironment = resolvedEnv || env;
argv.push('--env', testEnvironment);

jest.run(argv);

Now we can run rushx test inside of react-app project and test the shared configuration.

If you encountered any issues during the process, you can check all changes in this commit.

Build a scalable front-end with Rush monorepo and React — Repo Setup + Import projects + Prettier

Alexandru Bereghici — Wed, 17 Nov 2021 17:14:19 +0000

In a multi-repository project structure, it's only a matter of time when you'll need to reuse some code from one project to another. Adopting a monorepo architecture can help the team share and contribute code in a simple manner.
I won't cover in this article the pros and cons of choosing this approach, because there are plenty of resources that debate this topic, instead, I'll focus on the implementation of a scalable monorepo using Rush.js and React.

Tools

We'll be using the following tools:

Goals

Before implementing the monorepo, let's define the goals we want to achieve using these tools:

Multiple applications
Code sharing between applications
Shared tools and configurations
Enforced rules for code quality
Automated workflow for development

TL;DR

If you're interested in just see the code, you can find it here: https://github.com/abereghici/rush-monorepo-boilerplate

If you want to see an example with Rush used in a real, large project, you can look at ITwin.js, an open-source project developed by Bentley Systems.

Guide

Create a new repository

I assume you already created an empty Github repository for this project. Let's clone it locally and let the magic begin!

Initialize the rush monorepo

Inside of your project folder, run the following commands:

npm install -g @microsoft/rush

rush init

After this command, you'll see a bunch of files and folders created. You can check the config files reference here.

At this point, we can remove unnecessary files and create our first commit.

rm -rf .travis.yml

git add .
git commit -m "Initial commit"
git push origin master

Import existing projects without loosing git history

You don't really want to perform a migration to monorepo if you lose all the history of your projects. If everything will point to the commit where you merged the projects, you won't be able to revert to the previous commits, or run git blame or git bisect.

We can copy all projects inside of the monorepo and keep the git history of each project with a single git command: git subtree.

Let's suppose we want to import the following project into our monorepo https://github.com/abereghici/react-app. We'll do it using the command git subtree add

git subtree add --prefix apps/react-app \
 https://github.com/abereghici/react-app master

Let's decode the parameters of this command:

apps/react-app is used to specify the path inside of the monorepo where the project will be imported.
https://github.com/abereghici/react-app is the remote repository URL of the project we want to import.
master is the branch from where the project will be imported.

Now if you run git log you'll see the history of react-app project inside of our monorepo.

Open apps/react-app/package.json and change the name of the project with @monorepo/react-app.

The last step is to register @monorepo/react-app project in rush configuration file. Open rush.json file and add an entry like this under the projects inventory:

 "projects": [
    {
      "packageName": "@monorepo/react-app",
      "projectFolder": "apps/react-app",
      "reviewCategory": "production"
    }
  ]

This tells to Rush that it should manage this project. Next, run rush update to install the dependencies of react-app project. This command can be launched in any subfolder of the repo folder that contains rush.json file.

rush update
git add .
git commit -m "Imported react-app project"
git push origin master

Adding Prettier

We want to have consistent syntax and formatting across all code files in our monorepo. So we'll apply Prettier globally for the entire repository. We'll run it during git commit.

Let's create a configuration file in the root of the repo. Prettier allows many different names for this config file, but we'll use .prettierrc.js

<repo root>/.prettierrc.js

module.exports = {
  arrowParens: 'avoid',
  bracketSpacing: true,
  htmlWhitespaceSensitivity: 'css',
  insertPragma: false,
  jsxBracketSameLine: false,
  jsxSingleQuote: false,
  printWidth: 80,
  proseWrap: 'preserve',
  quoteProps: 'as-needed',
  requirePragma: false,
  semi: true,
  singleQuote: true,
  tabWidth: 2,
  trailingComma: 'es5',
  useTabs: false,
};

You also need to make a .prettierignore file to tell Prettier which files to skip. It is recommended for .prettierignore to extend the same patterns used in .gitignore.

cp .gitignore .prettierignore

Once the configuration is set up, next we need to invoke Prettier manually to reformat all the existing source files.

# See what files Prettier will format
# check the output and modify .prettierignore rules if needed
npx prettier . --list-different

# When you are ready, this will format all the source files
npx prettier . --write

To speed up the prettier process on git commit hook, we'll use prettier-quick to calculate the subset of files that are staged for commit and format them.

Let's create a rush auto-installer, where we'll list all dependencies for formatting.

# This creates the common/autoinstallers/rush-prettier/package.json file:
rush init-autoinstaller --name rush-prettier

Install the dependencies:


cd common/autoinstallers/rush-prettier

# Install the dependencies.
# You can also manually edit the "dependencies" in the package.json file
 pnpm install prettier
 pnpm install pretty-quick

# update the auto-installer
rush update-autoinstaller --name rush-prettier

Next, we will create a rush prettier custom command that invokes the pretty-quick tool. Add this to the "commands" section of config/rush/command-line.json file:


  . . .
  "commands": [
    {
      "name": "prettier",
      "commandKind": "global",
      "summary": "Used by the pre-commit Git hook. This command invokes Prettier to reformat staged changes.",
      "safeForSimultaneousRushProcesses": true,

      "autoinstallerName": "rush-prettier",

      // This will invoke common/autoinstallers/rush-prettier/node_modules/.bin/pretty-quick
      "shellCommand": "pretty-quick --staged"
    }
    . . .

After saving these changes, let’s test our custom command by running rush prettier.

The last step is to add a Git hook that invokes rush prettier automatically whenever git commit is performed.
Let's create a file called pre-commit in the common/git-hooks folder:

common/git-hooks/pre-commit

#!/bin/sh
# Called by "git commit" with no arguments.  The hook should
# exit with non-zero status after issuing an appropriate message if
# it wants to stop the commit.

# Invoke the "rush prettier" custom command to reformat files whenever they
# are committed. The command is defined in common/config/rush/command-line.json
# and uses the "rush-prettier" autoinstaller.
node common/scripts/install-run-rush.js prettier || exit $?

Install the hook by running rush install.

We're done! Now on every commit we'll be automatically prettified.

How to test your GitHub Pull Requests with CodeSandbox CI

Alexandru Bereghici — Thu, 11 Nov 2021 07:47:53 +0000

This article was originally posted here

If you're an open source project maintainer or you plan to create one, you should consider using CodeSandbox CI in your project configuration. CodeSandbox CI it's an awesome GitHub application that auto-builds your open source project from pull requests. This can save a lot of time and effort to test and approve the changes.

How does it work?

Whenever someone opens a new pull request, CodeSandbox CI builds a new version of your project. Those builds get posted to CodeSandbox registry, so you can test it in there or locally, and all without having to publish the build to npm⁠.

How do I set this up?

Let's create a demo project to see CodeSandbox CI in action. For that, create a new project on GitHub and name it, for example, codesandbox-ci-test. Clone it locally and add a package.json file with the following content:

{
  "name": "codesandbox-ci-test",
  "version": "1.0.0",
  "main": "dist/index.js",
  "engines": {
    "node": ">=12"
  },
  "scripts": {
    "build": "kcd-scripts build"
  },
  "peerDependencies": {
    "react": "^17.0.2"
  },
  "devDependencies": {
    "kcd-scripts": "^11.2.2",
    "react": "^17.0.2"
  },
  "dependencies": {
    "@babel/runtime": "^7.16.0"
  }
}

This is a standard package.json file for a JavaScript project. We'll be using kcd-scripts to build our project, and we'll be using react to create a small reusable component for this demo. @babel/runtime is required by kcd-scripts, otherwise it won't build the project.

In src/index.js create a simple Counter component:

import * as React from 'react';

export default function Counter() {
  const [count, setCount] = React.useState(0);

  return (
    <div>
      <p>You clicked {count} times!!!</p>
      <button onClick={() => setCount(count + 1)}>Click me</button>
    </div>
  );
}

Install the CodeSandbox Github application from https://github.com/apps/codesandbox in our new repository.

Create a file called ci.json in a folder called .codesandbox in the root of the repository and add:

{
  "buildCommand": "build",
  "node": "12",
  "sandboxes": ["/cra-template"]
}

buildCommand indicates which script in package.json should run to build the project.
node is the Node.js version to use for building the PR.
sandboxes is the list of sandboxes that we want to be generated. The default value is vanilla.

We don't want to use a default sandbox, because we'll have to modify manually the sandbox code to import and display the Counter component. Instead, we'll create a custom template, named cra-template.

Create a new folder named cra-template, inside of this folder create a package.json:

{
  "name": "react-starter-example",
  "version": "1.0.0",
  "description": "React example starter project",
  "main": "src/index.js",
  "dependencies": {
    "react": "17.0.2",
    "react-dom": "17.0.2",
    "react-scripts": "4.0.0"
  },
  "devDependencies": {
    "@babel/runtime": "7.13.8",
    "typescript": "4.1.3"
  },
  "scripts": {
    "start": "react-scripts start",
    "build": "react-scripts build",
    "test": "react-scripts test --env=jsdom",
    "eject": "react-scripts eject"
  },
  "browserslist": [">0.2%", "not dead", "not ie <= 11", "not op_mini all"]
}

Create a src folder and a index.js file with:

import { StrictMode } from 'react';
import ReactDOM from 'react-dom';
import Counter from 'codesandbox-ci-test';

const rootElement = document.getElementById('root');
ReactDOM.render(
  <StrictMode>
    <Counter />
  </StrictMode>,
  rootElement
);

Create a public folder with a index.html file with:

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8" />
    <meta
      name="viewport"
      content="width=device-width, initial-scale=1, shrink-to-fit=no"
    />
    <meta name="theme-color" content="#000000" />
    <link rel="manifest" href="%PUBLIC_URL%/manifest.json" />
    <link rel="shortcut icon" href="%PUBLIC_URL%/favicon.ico" />
    <title>React App</title>
  </head>
  <body>
    <noscript> You need to enable JavaScript to run this app. </noscript>
    <div id="root"></div>
  </body>
</html>

At this point we can create a new pull request and see our configuration in action. The CodeSandbox CI app will build the project and will leave a comment on the pull request.

You can checkout the following links to see the result:

CodeSandbox CI dashboard for PRs: https://ci.codesandbox.io/status/abereghici/codesandbox-ci-test/pr/1/builds/186555

CodeSandbox app: https://codesandbox.io/s/react-zmd24

Useful Links & Documentation

If you encountered any issues along the way, please check the Github repository https://github.com/abereghici/codesandbox-ci-test with the code from this article.

If you're interested in using CodeSandbox CI in a mono-repo project, you can check out the Design System project from Twilio https://github.com/twilio-labs/paste to see their configuration.

For more information about CodeSandbox CI, check out the documentation.

DEV Community: Alexandru Bereghici

Keeping your development resources organized with Notion

Structure

Bookmarks

Task List

Reading list

Saved Tweets

RSS Feed

Conclusion

Patch an NPM dependency with yarn

Headings & Accessibility

Cheat Sheets for Web Developers

General

Accessibility

HTML

CSS

Javascript

Typescript

Git

Design Patterns

Build a scalable front-end with Rush monorepo and React — VSCode

Install extensions

Add settings

Build a scalable front-end with Rush monorepo and React — Github Actions + Netlify

TL;DR

Create a Netlify site

Create Github Actions workflow

Build a scalable front-end with Rush monorepo and React — ESLint + Lint Staged

TL;DR

Build eslint-config package

Add lint command to react-scripts

Lint script in action

Add lint-staged command to react-scripts

Lint staged in action

Build a scalable front-end with Rush monorepo and React — Webpack + Jest

TL;DR

Create react-scripts package

Setup BrowserList

Setup Jest

Build a scalable front-end with Rush monorepo and React — Repo Setup + Import projects + Prettier

Tools

Goals

TL;DR

Guide

Create a new repository

Initialize the rush monorepo

Import existing projects without loosing git history

Adding Prettier

How to test your GitHub Pull Requests with CodeSandbox CI

How does it work?

How do I set this up?

Useful Links & Documentation