kaychaks / autopack Goto Github PK

View Code? Open in Web Editor NEW

15.0 2.0 0.0 638 KB

Auto build and run a React app within a Docker container without a Dockerfile

License: Apache License 2.0

Rust 100.00%

buildpack cli docker react rust web

autopack's Introduction

`autopack`

About

autopack creates Docker/OCI images of a React web application built using Create React App (CRA) tool. All that without any Dockerfile or any Docker mastery. It is available as a command line application (CLI) that run across Windows, Linux, and macOS.

For motivation and other details, check out the autopack RFC

Installation

Autopack is distributed via the pre-built binaries that one could install from the Releases page. Download, unzip, move the unzipped executable to have it available in your terminal's path, and then use the auto-pack command from your React project root folder.

Pre-requisties

autopack relies on Docker to run the built OCI images. So a relevant Docker runtime is required to be installed.

Currently, autopack only works for React projects built using CRA. It requires at least the build command to be present in the package.json.

Usage

> auto-pack --help
autopack 0.1.0
Auto Pack CLI

USAGE:
    auto-pack <SUBCOMMAND>

OPTIONS:
    -h, --help       Print help information
    -V, --version    Print version information

SUBCOMMANDS:
    build    Build auto-pack
    help     Print this message or the help of the given subcommand(s)
    init     Initializes auto-pack
    run      Runs auto-pack

Initialization

autopack initializes itself on the first run of this command. It will also download and install the required underlying tools.

Build

The build command generates the docker image.

Run

Run the container

Build from source

autopack is a Rust application. Follow the process of quickly setup the Rust development environment as mentioned here. And then

# build
$ cargo build
# run
$ cargo run init

autopack's People

Contributors

Stargazers

Watchers

autopack's Issues

Support other frameworks

autopack MVP would be launched with support for React based projects that too which are built using react-scripts.

To support other frameworks we need to at least have some ways to detect and then generalize the build requirements of all those frameworks. Some initial steps would be to look how to provide support for projects using Vite. That way autopack would automatically be opening support for multiple SPA frameworks other than React.

Replace Paketo buildpacks

Paketo buildpacks make it easy to compose tasks and also have readymade buildpacks for Node based projects. However there are few issues with them:

The [NodeJS buildpack](https://github.com/paketo-buildpacks/nodejs) which is a set of collaborating buildpacks is very generic and hence does lot of tasks which are not required for autopack. This leads to the build process taking a lot of time.
Collaborating buildpacks of NodeJS does not provide any way to change the start command of the final image. They set the same to npm run start or yarn start. This is not going to work for autopack since react-script start launches the webpack dev server. For autopack we need to build the React proeject and then launch it using some simple Node static app [serve](https://github.com/vercel/serve)r like Vercel's serve
Creating a custom buildpack set using only the relevant collaborating buildpacks would require using the Paketo's Go libraries like [Packit](https://github.com/paketo-buildpacks/packit). Using the same would mean including one more component to the current Rust based tool.

Apropos it's better to move away from Paketo buildpacks and create a simple buildpack in Rust following the Buildpack Interface Specification which is going to be custom for autopack with necessary extension points. Tasks that necessarily would be required for such a custom buildpack:

Install node (other system level s/w like SSL certs etc.)
    this should ideally be following these Paketo buildpacks - [Node Engine CNB](https://github.com/paketo-buildpacks/node-engine), [Yarn CNB](https://github.com/paketo-buildpacks/yarn), [Environment Variables CNB](https://github.com/paketo-buildpacks/environment-variables), [Image Labels CNB](https://github.com/paketo-buildpacks/image-labels), [CA Certificates CNB](https://github.com/paketo-buildpacks/ca-certificates)
Install yarn (if required)
npm install or yarn install
    take inspirations from [Yarn Install CNB](https://github.com/paketo-buildpacks/yarn-install), [NPM Install CNB](https://github.com/paketo-buildpacks/npm-install)
setup launch command

COW for Strings

Strings abound in the implementation of autopack. I could feel during implementation that there are instances where we can live without explicit copying of data as we are allocating to heap or cloning/copying. I think the Cow<'static, str> in place of String in some places would make more sense and improve the performance a lot.

References:

https://users.rust-lang.org/t/can-anyone-explain-me-cow/32538/2

Option for having silent execution

An option like --quiet or -q to hide all user facing messages on auto-pack build or auto-pack run. The option should not hide the success message though.

Info command

auto-pack info

version of autopack
name of the current project being managed
docker image name
when was the docker image last built
launch command
pack cli version

Daemonizing run

auto-pack run --daemon should run autopack in the background thereby auto-building on every source code change. This would result in a better developer experience. However, some things need to be taken care:

since a project's production build takes more time than mere starting the development server the daemon should not stop the existing running server. However, it should in some way overlay information on the running app that a new image is being built. This would require runtime code injection to the running application.
also we need to have some way of incremental code replacement of the built artefacts unless the build tool already supports that. One way is to volume mount the dist folder to the docker container rather than bundling it and only rebuilding the image if there is any change in the package.json.