quinta-feira, novembro 03, 2022

React example with Yarn

 https://codefresh.io/docs/docs/learn-by-example/nodejs/react/


React example with Yarn

Create Docker images for React applications

Codefresh can work with React projects as with any Node.js project.

The example React project

You can see the example project at https://github.com/codefresh-contrib/react-sample-app. The repository contains a React starter project with the following tasks:

  • yarn test runs unit tests.
  • yarn start to start the application locally.
  • yarn build to create a production deployment.

Once launched the application presents a simple page at localhost:3000.

React and Docker (multi-stage builds)

The easiest way to build a React.JS application is with multi-stage builds. With multi-stage builds a Docker build can use one base image for packaging/unit tests and a different one that will hold the runtime of the application. This makes the final image more secure and smaller in size (as it does not contain any development/debugging tools).

In the case of React, you can use a base image that has Node and all testing utilities, while the final image has your server (e.g. nginx) with the static content and nothing else.

The example project is actually using multi-stage builds by default.

Here is the multi-stage Dockerfile:

Dockerfile

FROM node:8.16 as build-deps
WORKDIR /usr/src/app
COPY package.json yarn.lock ./
RUN yarn
COPY . ./
RUN yarn build

FROM nginx:1.12-alpine
COPY --from=build-deps /usr/src/app/build /usr/share/nginx/html
EXPOSE 80
CMD ["nginx", "-g", "daemon off;"]

This docker build does the following:

  1. Starts from the Node/Yarn image
  2. Copies the dependencies inside the container
  3. Copies the source code and creates all static files
  4. Discards the Node.js image with all the JavaScript libraries
  5. Starts again from the nginx image and copies static build result created before

The resulting is very small, as it contains only packaged/minified files.

Create a CI pipeline for React.js (Docker build)

Creating a CI/CD pipeline for React is very easy, because Codefresh can run any node image that you wish.

Creating a Docker image for react.js

Creating a Docker image for react.js

Here is the full pipeline that creates the Docker image after checking out the code.

codefresh.yml

version: '1.0'
stages:
  - prepare
  - test
  - build
steps:
  main_clone:
    title: Cloning main repository...
    stage: prepare
    type: git-clone
    repo: 'codefresh-contrib/react-sample-app'
    revision: master
    git: github
  MyUnitTests:
    title: Unit test
    stage: test
    image: node:8.16
    commands:
      - yarn install
      - yarn test
    environment:
      - CI=true
  MyAppDockerImage:
    title: Building Docker Image
    type: build
    stage: build
    image_name: react-sample-app
    working_directory: ./
    tag: 'with-nginx'
    dockerfile: Dockerfile

This pipeline clones the source code, runs unit tests and finally creates a Docker image. Codefresh is automatically caching Docker layers (it uses the Docker image of a previous build as a cache for the next) and therefore builds will become much faster after the first one finishes.

Building a React.Js application without Docker

If your application is not dockerized yet, you can still create a pipeline that runs any command that you would run locally. You can also choose which Node version is used for each step of the pipeline by defining a different docker image for each step.

Building a Reach.js application

Building a Reach.js application

Here is the full pipeline that creates a production deployment of all files.

codefresh.yml

version: '1.0'
stages:
  - prepare
  - test
  - build
steps:
  main_clone:
    title: Cloning main repository...
    stage: prepare
    type: git-clone
    repo: 'codefresh-contrib/react-sample-app'
    revision: master
    git: github
  MyUnitTests:
    title: Unit test
    stage: test
    image: node:11.0
    commands:
      - yarn install
      - yarn test
    environment:
      - CI=true
  MyReactBuild:
    title: Packaging application
    stage: build
    image: node:8.16
    commands:
      - yarn build

Notice that for demonstration purposes we uses node 11 for the tests, and node 8 for the packaging. Normally you should use the same version of node/Yarn for all your steps, but Codefresh pipelines are flexible on version of tools.

Even when you don’t create a Docker image, Codefresh still caches your workspace volume. This means that node_modules are downloaded only once. All subsequent builds will be much faster.

at Nenhum comentário:

Reactjs Build Production: Creating a Deployment Build That Optimizes Performance

 https://www.copycat.dev/blog/reactjs-build-production/


...

...

Additional ways of Reactjs build production

In the above demo, we used the npm run build command provided by the Create React App (CRA) for creating our production build. There are also other tools through which you can generate your prod build. Likewise, let us discuss a few of them in this section.

  1. Brunch

Brunch is a Fast front-end web app build tool useful for efficiently creating production build.

at Nenhum comentário:

quarta-feira, julho 06, 2022

Zsh on Windows via MSYS2

Source -> Visit the author

Zsh on Windows via MSYS2

set CHERE_INVOKING=1 & 
	set MSYSTEM=MINGW64 & 
	set MSYS2_PATH_TYPE=inherit & 
	set "MSYS2_PATH=D:\Users\USER\scoop\apps\msys2\current" & 
	set "PATH=%MSYS2_PATH%\usr\bin;%MSYS2_PATH%\mingw64\bin;%PATH%" & 
	"%ConEmuBaseDirShort%\conemu-msys2-64.exe" "/usr/bin/bash.exe" --login -i -new_console:p:C:"%MSYS2_PATH%\msys2.ico"

MSYS2

  • MSYS2 (usually upper case) consists of three relatively separate subsystems: msys2 , mingw32 and mingw64.
  • msys2 (sometimes called just msys) is an emulation layer — fully POSIX compatible but slow.
  • mingw subsystems provide native Windows binaries, with Linux calls rewritten at compile time to their Windows equivalents. For example, Git for Windows is a mingw64 binary (unlike msys Git which utilizes the compatibility layer and is therefore slow).
  • Each subsystem has its own shell and it’s important to be in the right one. The msys shell has a PATH starting with /usr/local/bin:/usr/bin:/bin:... while the mingw64 shell adds /mingw64/bin before it. This means that /mingw64/bin/git.exe is only available in the mingw64 shell.
  • MSYS2 comes with Pacman, a package manager ported from Arch Linux, and many packages installable by pacman -S <package>.
pacman -Syu # repeat if necessary
pacman -Su

$HOME

HOME = C:\Users\You
db_home: windows cygwin desc

ConEmu with mingw shell

  1. I didn’t hit any issues installing packages from the mingw shell.
  2. I did hit issues installing mingw-w64-x86_64-git-lfs from the msys shell, because it uses git as part of its installation which is not in msys’ PATH.
  3. Worrying about two shells, two ConEmu tasks, two PATH configurations, etc. is IMO not worth it until proven otherwise.
set CHERE_INVOKING=1 & set MSYSTEM=MINGW64 & set MSYS2_PATH_TYPE=inherit & set “PATH=%ConEmuDrive%\msys64\mingw64\bin;%ConEmuDrive%\msys64\usr\bin;%PATH%” & %ConEmuBaseDirShort%\conemu-msys2–64.exe -new_console:p %ConEmuDrive%\msys64\usr\bin\bash.exe — login -i -new_console:C:”%ConEmuDrive%\msys64\msys2.ico”

Essential utilities

pacman -S man vim nano
pacman -S openssh rsync make
pacman -S zip unzip
pacman -S mingw64/mingw-w64-x86_64-jq

Git for Windows

[git-for-windows]
Server = https://wingit.blob.core.windows.net/x86-64
curl -L https://raw.githubusercontent.com/git-for-windows/build-extra/master/git-for-windows-keyring/git-for-windows.gpg |
pacman-key --add - &&
pacman-key --lsign-key 1A9F3986
pacman -Syu
pacboy sync git:x git-credential-manager:x git-lfs:x git-doc-html:x git-doc-man:x
$ git --version
git version 2.18.0.windows.1$ git config --list --show-origin
# ... verifies that your ~/.gitconfig is read

Update Windows path

C:\msys64\mingw64\bin
C:\msys64\usr\bin
Microsoft Windows [Version 10.0.17134.112]
(c) 2018 Microsoft Corporation. All rights reserved.C:\Users\Borek>git --version
git version 2.18.0.windows.1C:\Users\Borek>ls -la
...

Zsh

pacman -S zsh
set CHERE_INVOKING=1 & set MSYSTEM=MINGW64 & set MSYS2_PATH_TYPE=inherit & set “PATH=%ConEmuDrive%\msys64\mingw64\bin;%ConEmuDrive%\msys64\usr\bin;%PATH%” & %ConEmuBaseDirShort%\conemu-msys2–64.exe -new_console:p %ConEmuDrive%\msys64\usr\bin\zsh.exe — login -i -new_console:C:”%ConEmuDrive%\msys64\msys2.ico”

Oh My Zsh

# Use the path where you installed Antigen
source "${funcsourcetrace[1]%/*}/antigen.zsh"# Load Oh My Zsh
antigen use oh-my-zsh# Example of how to add other useful things
antigen bundle zsh-users/zsh-completionsantigen apply
# Make /c/... autocompletion work, see Alexpux/MSYS2-packages#38
zstyle ':completion:*' fake-files /: '/:c'# Convenient path navigation, e.g., `cd vp`
setopt CDABLE_VARS
vp="/c/Dev/VersionPress/versionpress"
temp="/c/Dev/temp"# VSCode as an editor
if [[ -n $SSH_CONNECTION ]]; then
  export EDITOR='vim'
else
  export EDITOR='code-insiders --wait'
fi

Prompt

  1. It should be simple, like Pure.
  2. It must be asynchronous so that querying Git info doesn’t block the actual work.
antigen theme borekb/agkozak-zsh-theme@prompt-customization
at Nenhum comentário:
Assinar: Postagens (Atom)