buildpacks-nodejs
moon
buildpacks-nodejs | moon | |
---|---|---|
3 | 6 | |
24 | 2,587 | |
- | 1.1% | |
9.3 | 9.7 | |
6 days ago | 6 days ago | |
Rust | Rust | |
BSD 3-clause "New" or "Revised" License | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
buildpacks-nodejs
- An open-source alternative to Heroku based on Kubernetes and Istio
-
12 Things You Might Not Know About Buildpacks
The Paketo Buildpacks are mostly written in Go, while the Heroku buildpacks are written in Bash and Rust. The libcnb library is a Go language binding of the Cloud Native Buildpacks API. It's supported by the project, but there are also libraries outside of the project like libcnb.bash.
- Free alternatives to Heroku with free SQL database
moon
-
Launch HN: Moonrepo (YC W23) โ Open-source build system
(for context - I'm not interested in first class node support)
This seems pretty cool. I particularly like how 'gradual' it seems to be relative to things like Bazel, i.e. you can take some shell scripts and migrate things over. I did have a play and hit an initial problem around project caching I think, which I raised at [0].
One comment, from the paranoid point of view of someone who has built distributed caching build systems before is that your caching is very pessimistic! I understand why you hash outputs by default (as well as inputs), but I think that will massively reduce hit rate a lot of the time when it may not be necessary? I raised [1].
As an aside, I do wish build systems moved beyond the 'file-based' approach to inputs/outputs to something more abstract/extensible. For example, when creating docker images I'd prefer to define an extension that informs the build system of the docker image hash, rather than create marker files on disk (the same is true of initiating rebuilds on environment variable change, which I see moon has some limited support for). It just feels like language agnostic build systems saw the file-based nature of Make and said 'good enough for us' (honorable mention to Shake, which is an exception [2]).
[0] https://github.com/moonrepo/moon/issues/637
- A build system and repo management tool for the web ecosystem, written in Rust
-
Building a full-stack TypeScript application with Turborepo
There are many tools like Lerna, Nx, Turborepo, Moon, Rush, and Bazel, to name a few. Today, we'll be using Turborepo, as it's lightweight, flexible, and easy to use.
-
Lerna reborn - What's new in v6?
You should give moon a try: https://moonrepo.dev/
- Moon - A build system for the javascript ecosystem, written in rust.
What are some alternatives?
buildpacks-jvm - Heroku's Cloud Native Buildpacks for JVM applications.
hash - ๐ The open-source, self-building database. From @hashintel
dilbert-viewer - A simple comic viewer for Dilbert by Scott Adams
orogene - Makes `node_modules/` happen. Fast. No fuss.
libcnb.bash - A library for common buildpack functions
nx - Smart Monorepos ยท Fast CI
ny - ๐ฝ Fast, Proxy Package Manager for JavaScript
mandelbrot - Microbenchmark testing Python, Numba, Mojo, Dart, C/gcc, Rust, Go, JavaScript, C#, Java, Kotlin, Pascal, Ruby, Haskell performance in Mandelbrot set generation
sidekiq - Sidekiq worker on Render
napi-rs - A framework for building compiled Node.js add-ons in Rust via Node-API
nuke - ๐ A Node.js version manager for windows without pain.
hackerman - Cargo hack manager