DEV Community: Florentin / 珞辰

React Native + Next.js Monorepo

Florentin / 珞辰 — Sun, 14 Nov 2021 11:23:22 +0000

Preamble

If you need an introduction to Yarn Workspaces: Yarn Blog

If you prefer looking at the finished repository: GitHub

Initial Setup

Our goal for this blog post is to have a basic monorepo setup that contains one bare React Native app and one Next.js project. This will result in a file structure like this:

monorepo-tutorial
├── package.json
└── packages
    ├── app
    └── web

For starters we create our root directory and initialize a fresh project with git repository.

mkdir monorepo-tutorial && cd monorepo-tutorial && yarn init -y && echo node_modules > .gitignore && git init

Since both of our packages will depend on react we will lift up the dependency to the root level of our monorepo. Note that we also add react-dom in case we want to create more web packages later.

yarn add -W react react-dom

In our package.json we define a workspace structure. The below glob defined in workspaces tells Yarn where our monorepo packages are located.

{
+ "private": true,
+ "name": "root",
  "version": "1.0.0",
  "main": "index.js",
  "author": "ecklf",
  "license": "MIT",
+ "workspaces": [
+   "packages/*"
+ ]
}

We can now proceed with creating our packages folder.

mkdir packages && cd packages

React Native

Let's start by initializing a fresh React Native project from the template:

npx react-native init app --template react-native-template-typescript

You should now encouter this error:

Failed to install CocoaPods dependencies for iOS project.

This is perfectly fine since the template's CocoaPods configuration has the wrong path to react-native.

Continue by removing the react dependency from the template since we will resolve it from the root level.

cd app
yarn remove react

From my experience Metro plays the nicest in monorepos when launched separately with yarn start, so we disable the packaging when running ios / android scripts. While we are at it we can also update the name in our package.json.

{
+ "private": true,
+ "name": "@monorepo/app",
  "version": "1.0.0",
  "main": "index.js",
  "author": "ecklf",
  "license": "MIT",
  "scripts": {
-   "android": "react-native run-android",
+   "android": "react-native run-android --no-packager",
-   "ios": "react-native run-ios",
+   "ios": "react-native run-ios --no-packager",
  },
}

React Native Configuration

Create the file react-native.config.js with the following content:

+ module.exports = {
+   reactNativePath: '../../node_modules/react-native',
+ };

Metro Configuration

Update metro.config.js to have an additional watch folder at root level.

+ const path = require('path');

module.exports = {
+ watchFolders: [path.resolve(__dirname, '../../')],
  transformer: {
    getTransformOptions: async () => ({
      transform: {
        experimentalImportSupport: false,
        inlineRequires: true,
      },
    }),
  },
};

Babel Configuration

We need to add aliases to explicitly define where our root-level packages are located in babel.config.js.

yarn add -D @babel/runtime babel-plugin-module-resolver

const path = require("path");

module.exports = {
  presets: ["module:metro-react-native-babel-preset"],
  plugins: [
    [
      "module-resolver",
      {
        root: ["./src"],
        alias: {
          react: require.resolve("react", {
            paths: [path.join(__dirname, "./")],
          }),
          "^react-native$": require.resolve("react-native", {
            paths: [path.join(__dirname, "./")],
          }),
          "^react-native/(.+)": ([, name]) =>
            require.resolve(`react-native/${name}`, {
              paths: [path.join(__dirname, "./")],
            }),
        },
        extensions: [
          ".ios.js",
          ".ios.ts",
          ".ios.tsx",
          ".android.js",
          ".android.ts",
          ".android.tsx",
          ".native.js",
          ".native.ts",
          ".native.tsx",
          ".js",
          ".ts",
          ".tsx",
        ],
      },
    ],
  ],
};

iOS / iPadOS

Podfile

First, we fix our previous install error by now pointing to our root's node_modules folder.

- require_relative '../node_modules/react-native/scripts/react_native_pods'
+ require_relative '../../../node_modules/react-native/scripts/react_native_pods'
- require_relative '../node_modules/@react-native-community/cli-platform-ios/native_modules'
+ require_relative '../../../node_modules/@react-native-community/cli-platform-ios/native_modules'

We can confirm if this worked by installing our pods:

npx pod install

Xcode (workspace) - Signing & Capabilities

Add your development team to build the project.

Xcode (workspace) - Build Phases

Nothing special here. We just adjust the paths like in CocoaPods.

Start Packager

- echo "export RCT_METRO_PORT=${RCT_METRO_PORT}" > "${SRCROOT}/../node_modules/react-native/scripts/.packager.env"
+ echo "export RCT_METRO_PORT=${RCT_METRO_PORT}" > "${SRCROOT}/../../../node_modules/react-native/scripts/.packager.env"

- open "$SRCROOT/../node_modules/react-native/scripts/launchPackager.command" || echo "Can't start packager automatically"
+ open "$SRCROOT/../../../node_modules/react-native/scripts/launchPackager.command" || echo "Can't start packager automatically"

Xcode (workspace) - Bundle React Native code and images

- ../node_modules/react-native/scripts/react-native-xcode.sh
+ ../../../node_modules/react-native/scripts/react-native-xcode.sh

Build Settings

User-Defined

Add a user-defined setting (+ sign at the top menu bar) RCT_NO_LAUNCH_PACKAGER with the value 1.

Android

Getting things to work on Android is just a matter of adding paths for hermes + react-native cli and updating the existing ones.

android/build.gradle

maven {
    // All of React Native (JS, Obj-C sources, Android binaries) is installed from npm
-   url("$rootDir/../node_modules/react-native/android")
+   url("$rootDir/../../../node_modules/react-native/android")
}
maven {
    // Android JSC is installed from npm
-   url("$rootDir/../node_modules/jsc-android/dist")
+   url("$rootDir/../../../node_modules/jsc-android/dist")
}

android/settings.gradle

- apply from: file("../node_modules/@react-native-community/cli-platform-android/native_modules.gradle"); applyNativeModulesSettingsGradle(settings)
+ apply from: file("../../../node_modules/@react-native-community/cli-platform-android/native_modules.gradle"); applyNativeModulesSettingsGradle(settings)

app/build.gradle

project.ext.react = [
-  enableHermes: false,  // clean and rebuild if changing
+  enableHermes: true,  // clean and rebuild if changing
+  hermesCommand: "../../../../node_modules/hermes-engine/%OS-BIN%/hermesc",
+  composeSourceMapsPath: "../../node_modules/react-native/scripts/compose-source-maps.js",
+  cliPath: "../../node_modules/react-native/cli.js"
]

- apply from: "../../node_modules/react-native/react.gradle"
+ apply from: "../../node_modules/react-native/react.gradle"

- def hermesPath = "../../node_modules/hermes-engine/android/";
+ def hermesPath = "../../../../node_modules/hermes-engine/android/";

- apply from: file("../../node_modules/@react-native-community/cli-platform-android/native_modules.gradle"); applyNativeModulesAppBuildGradle(project)
+ apply from: file("../../../../node_modules/@react-native-community/cli-platform-android/native_modules.gradle"); applyNativeModulesAppBuildGradle(project)

Testing the Configuration

yarn start

yarn ios
yarn android

Next.js

Fortunately adding a Next.js project is more straightforward. All we need to do is delete package-lock.json (we use yarn not npm) and remove our root dependencies from the template.

npx create-next-app@latest --ts web

rm package-lock.json && yarn remove react react-dom

{
+ "private": true,
+ "name": "@monorepo/web",
+ "version": "1.0.0",
  "main": "index.js",
  "author": "ecklf",
  "license": "MIT",
}

Configuring 2FA on your Linux Server

Florentin / 珞辰 — Wed, 16 Jun 2021 21:36:03 +0000

Recommended Setup

Update your server to the latest packages.

sudo apt update && apt upgrade && reboot

Add a non-root user with sudo privileges.

adduser username
usermod -aG sudo username
su username

Time-based One-time Password Authentication

First, install the Google Authenticator PAM module.

sudo apt install libpam-google-authenticator

Run the google-authenticator binary to create a new secret key (keep this one safe).

google-authenticator

After completing the process, you can scan/enter the code in an Authenticator App.

I've chosen the following settings for this example.

Do you want authentication tokens to be time-based (y/n) y

Do you want me to update your "/home/username/.google_authenticator" file? (y/n) y

Do you want to disallow multiple uses of the same authentication
token? This restricts you to one login about every 30s, but it increases
your chances to notice or even prevent man-in-the-middle attacks (y/n) n

By default, a new token is generated every 30 seconds by the mobile app.
In order to compensate for possible time-skew between the client and the server,
we allow an extra token before and after the current time. This allows for a
time skew of up to 30 seconds between authentication server and client. If you
experience problems with poor time synchronization, you can increase the window
from its default size of 3 permitted codes (one previous code, the current
code, the next code) to 17 permitted codes (the 8 previous codes, the current
code, and the 8 next codes). This will permit for a time skew of up to 4 minutes
between client and server.
Do you want to do so? (y/n) y

If the computer that you are logging into isn't hardened against brute-force
login attempts, you can enable rate-limiting for the authentication module.
By default, this limits attackers to no more than 3 login attempts every 30s.
Do you want to enable rate-limiting? (y/n) y

To finish the Setup, we need to add the authentication module to the OpenSSH daemon.

sudo vim /etc/pam.d/sshd

# Standard Un*x password updating.
@include common-password
+ auth required pam_google_authenticator.so

sudo vim /etc/ssh/sshd_config

// We created a non-root user with sudo privileges earlier, so we can disable
- PermitRootLogin yes
+ PermitRootLogin no

- ChallengeResponseAuthentication no
+ ChallengeResponseAuthentication yes

// Restart to pick up changes
sudo systemctl restart sshd

Hardware-based Authentication with YubiKey

Check if OpenSSH 8.2 or higher is installed on your server for FIDO (Fast Identity Online) U2F support.

lsb_release -d && ssh -V
Description:    Ubuntu 20.04.2 LTS
OpenSSH_8.2p1 Ubuntu-4ubuntu0.2, OpenSSL 1.1.1f  31 Mar 2020

Create a new SSH key pair with ecdsa-sk or ed25519-sk. Please note that ed25519-sk only works if your YubiKey runs on Firmware >=5.2.3.
To determine your firmware, you can use ykman or YubiKey manager.

brew install ykman
ykman list
Firmware version: 5.2.7

// Using ed25519-sk since Firmware of my YubiKey >=5.2.3
// macOS may throw "unknown key type ed25519-sk", run "brew install openssh" to fix this issue
ssh-keygen -t ed25519-sk -f ~/.ssh/$(hostname)-yk_id

If you didn't set up a FIDO PIN, the first thing you should see is:

You may need to touch your authenticator to authorize key generation

Touch the YubiKey disk and finish the Setup.

For the last step, you'll add the generated public key to your server's ~/.ssh/authorized_keys.

ssh-copy-id -i ~/.ssh/hostname-yk_id username@IP

Logging into the server will now ask you for a password (if defined) and a physical touch on your YubiKey.

ssh -i ~/.ssh/hostname-yk_id username@IP

You can repeat the above steps for multiple keys.

Why Tailwind? A long term user perspective

Florentin / 珞辰 — Mon, 10 May 2021 07:37:11 +0000

Disclaimer: I don't want to engage in the drama. I just think it's important to share experiences to help people make a choice.

Prelude

I've been using Tailwind CSS for roughly 3 years now, and it is currently my go-to solution for starting a new project.

As for any of my favorite tools, I love recommending them to other fellow developers. Thus over the years, I've engaged in many conversations discussing the pros and cons of using it.

The following is a collection of statements I've encountered and my stance on why I think they are not justified.

“Tailwind is for people who don't want / are too lazy to learn CSS”

Let's start with my backstory of how I learned about Tailwind. In 2018 I decided to volunteer for a project to gain more experience building things for the web. My CSS knowledge back then was mediocre at best, and therefore I didn't enjoy participating in styling the frontend. Soon after, the project's management wanted a fresh look. One guy suggested: "Let's use Tailwind for the refresh. We use it at (name of one of the biggest companies in Germany) and we love it". So I took this opportunity to learn to style for real this time.

So what was the experience of learning CSS with Tailwind?

Spoiler: It made me understand CSS more

The reason why I didn't know much about CSS was that it just felt uncomfortable to learn. I would consider myself as a person who has a lot of grit when it comes to learning new things, but I kept getting frustrated about figuring out where to put which property to make things work. Utility classes just eliminated this issue for me because you directly see what styling affects which element. When it comes to learning new things, the initial step is the hardest, and I think utility-first played the leading role in making it click.

Another point I would like to bring up is to figure out how to learn to make things look pretty. Most of the modern web has styling hidden behind hashed class names which may be more performant but are super intimidating for a beginner.

Especially for Tailwind, there are tons of resources to learn from. High-quality open-source projects like Vercel's commerce, component platforms like tailwindcomponents or if you prefer videos the Tailwind Labs YouTube channel. There are also tools like Windy, which allows you to transform page content into Tailwind-styled markup to get a better understanding.

“You need to learn the syntax and neglect vanilla CSS”

Personally, readability has never been an issue for me to begin with, but starting from v1, Tailwind has seen massive improvements in this regard. At this point, it feels like writing CSS properties in a kebab-case syntax.

Some people have also raised concerns that switching to utility classes for too long will make their vanilla CSS suffer. From personal experience, I can say that I worked on projects that only use CSS-in-JS libraries and I didn't face any issues transitioning over to writing regular syntax.

CSS-in-JS is often praised as the solution when I ask people what they are using instead. Whether or not to use CSS-in-JS boils down to preference, but be aware you can use both with libraries like twin.macro (see Tailwind adds no value and does not scale on why you would still want it). As for my part, I find it easier to modify my styling without jumping around my component's file.

“Utility classes make the HTML look ugly and refactoring harder”

Bloating the HTML by eliminating the separation of concerns is a trade-off. But what are the alternatives that work better? All I can say that I just love to get an idea of how something looks by just looking at utility-flavored markup. Using components also makes this issue and the hassle of refactoring way less relevant than people make it out to be. It just takes a different approach that admittedly takes some time getting used to.

I can suggest taking a look at Tailwind CSS Best Practice Patterns and Robin Malfait's Good Example to get an idea of how that would look like. For consistency, I can also recommend having a convention for class ordering or using headwind as an opinionated class sorter.

“Building pixel-perfect designs takes longer”

Fortunately, this won't be an issue anymore, and you can already opt-in today! Tailwind Labs has released a Just-in-Time (JIT) preview, which allows you to inline arbitrary spacing and color values for "single-use-values". Don't overdo it though.

“Tailwind builds are slow and require extra tooling”

I mention this since JIT mode is still in preview but will eventually eliminate this issue as well. Tailwind generates lots of classes, so you need to strip out the unused ones for production builds. Back in older versions, this required setting up purgecss. Credit where credit's due it later was merged into Tailwind to make it even easier for people to get optimized production builds.

“Tailwind does not provide XYZ”

Tailwind was designed with customization in mind, and if you don't want to make a Plugin for it, nothing will stop you from adding a bit of custom CSS.

“Tailwind adds no value and does not scale”

I often hear this from people who presumably never gave the framework a proper try.

The most value Tailwind adds to my projects can be summarized in two words: Design constraints

Using the ecosystem as a team will make you appreciate Tailwind in a scaling project as it's just so convenient to work with it. I think many people just get the wrong idea by looking at Tailwind's defaults. You can narrow down choices, or you can ditch them altogether. You don't need to keep names like text-red-500 and go with more generic terms. What does matter is that developers can adhere to style choices from one single Source of Truth. All that's left is to install autocompletion for the supported editors, and you will find yourself creating layouts at a huge pace.

So should I use it?

Everything is a trade-off, and I won't force you to use Tailwind if you don't like it.

Will / is there a better solution? Maybe, but I think the resources and tooling are great (if not the best) right now.

Just give it a try. You can join the official Discord here if you have any questions.