Code Monkey home page Code Monkey logo

autopack's People

Contributors

kaychaks avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar

autopack's Issues

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.

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.

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.

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:

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.