-
yplatform
Self-service bootstrap/build/CI/CD. Software and configuration that supports various cycles of software development.
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
quickjs-emscripten
Safely execute untrusted Javascript in your Javascript, and execute synchronous code that uses async functions
-
SheetJS js-xlsx
📗 SheetJS Spreadsheet Data Toolkit -- New home https://git.sheetjs.com/SheetJS/sheetjs
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
turborepo
Discontinued Incremental bundler and build system optimized for JavaScript and TypeScript, written in Rust – including Turborepo and Turbopack. [Moved to: https://github.com/vercel/turbo]
-
cod-stats
All-inclusive ETL pipeline to pull Modern Warfare statistics and generate statistical reporting for a playgroup
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
https://github.com/ysoftwareab/yplatform that this a notch higher (disclaimer: author here)
As others have mentioned on this thread, the problem is not just "use Makefiles instead of package.json scripts", but quickly ending up with duplicate Makefile content and then supporting more than just one language. It's inevitable.
PS
for those that don’t know, npm’s “scripts” functionality as we know it today was not “designed”, but it was simply a byproduct.
First introduced as an internal functionality for lifecycle support https://github.com/npm/npm/commit/c8e17cef720875c1f7cea1b49b... on 1 Mar 2010
and later extend to run arbitrary targets https://github.com/npm/npm/commit/9b8c0cf87a9d4ef560e17e060f... on 13 Dec 2010
This is the entire design backstory https://github.com/npm/npm/issues/298 .
Needless to say that GNU Make’s equivalent (or any other build system) is not to be found in npm’s scripts.
https://github.com/awinecki/magicfile
People call this "self-documenting makefile".
It migrated with me from company to company, from project to projects. Through node, php, aws, docker, server management, cert updates, file processing and many many more.
I like Make, and use it in personal JavaScript ecosystem projects that do actually need to build things with interdependency (eg https://github.com/justjake/quickjs-emscripten/blob/master/M...). I’ve also seen Makefiles grown to be horrendous monstrosities masquerading as command-line tools; for about a year at Airbnb we used a 1000 line Makefile as the main tool for fiddling with Kubernetes cuz one of our senior engineers didn’t like Ruby.
What I learned from supporting Make and shell among a few different audiences is that most developers have no idea how to write or maintain shell-like tooling. They forget or mess up quoting rules constantly, and eschew learning things and good design in these tools to a much greater degree than in their “normal” work in Java/Python/Ruby/Typescript/Golang.
For every POSIXly Correct HN Commenter (of which I count myself a member), there’s 100 regular software engineers who won’t read a `man` page on what $@ or $< mean in Make. I know that if I start writing a Makefile for $JOB, it’s gonna be me and that one guy who uses tcsh who are gonna maintain it and answer questions.
(Although for what it’s worth we don’t use package.json either thank goodness. All our complicated build steps are typescript commands, and our glue is CI system YAML files.)
For a lot of the same reasons in this article I like to use tup[0] when I can. It doesn't integrate into anything which is both good and bad. I wish my IDE could check with tup to see what dependencies get pulled in by what files. However, it's nice that it doesn't care what language or ecosystem I'm using.
Also I can get a neat dependency graph as a PNG if I want.
[0] https://gittup.org/tup/
Make is an incredible swiss army knife, and we use it for most JS projects (e.g. https://github.com/SheetJS/sheetjs/blob/master/Makefile)
The main reasons to prefer package.json scripts are portability (works on windows without figuring out WSL) and binary paths. Years ago it was popular to install command-line tools globally, but now the trend is to favor local installations and run with `npx`. `package.json` scripts will do the "right thing", but `eslint` in a makefile will look for a system-wide `eslint` installation.
I would like to call attention to `just` (https://github.com/casey/just) which is a modern take on "make if we didn't have to keep it backwards compatible", and more focussed on just task running rather than tracking dependencies.
I was amazed to discover Taskfile. Didn't realise it was a copy of Make.
https://github.com/adriancooney/Taskfile
No, that's why there's a bunch of packages such as rimraf[0] that implements that sort of functionality in a cross-platform way that most people use in their scripts
[0]: https://www.npmjs.com/package/rimraf
> - Compile this Rust app with Cargo then flash it to the esp32? Make.
Why not something like this?
> cargo run --bin uno-blink
https://github.com/Rahix/avr-hal
We are using make targets to automate ci/cd, local dev and a lot of other things by adding a set of easy to extend, customise template makefiles as submodules.
The main advantage for us is it's same everywhere and it's agnostic to underlying technologies. (we are only supporting unix based environments and have guidelines to setup gnumake in macos)
We are also using make targets to document themselves. How to use, what are other targets, variables you need to define etc. This makes it a powerful CLI app for us that can run and support many things.
For anyone interested: https://gitlab.com/ska-telescope/sdi/ska-cicd-makefile
I've been using GNU Make 4.2.1 from here: https://github.com/mbuilov/gnumake-windows - depends only on kernel32.dll. I assume the latest 4.3 build there is the same.
Why I prefer package.json over makefiles:
- turborepo (https://turborepo.org/) can describe dependency pipelines and provide automatic caching. Makefiles aren't designed for multi-input, multi-output scenarios - its really awkward: https://www.gnu.org/software/automake/manual/html_node/Multi... and https://stackoverflow.com/questions/39237306/makefile-compil...
- turborepo can also run never-ending targets in parallel (e.g. API server and static file server in development mode). Not sure how well make supports that
https://github.com/ysoftwareab/yplatform that this a notch higher (disclaimer: author here)
As others have mentioned on this thread, the problem is not just "use Makefiles instead of package.json scripts", but quickly ending up with duplicate Makefile content and then supporting more than just one language. It's inevitable.
PS
for those that don’t know, npm’s “scripts” functionality as we know it today was not “designed”, but it was simply a byproduct.
First introduced as an internal functionality for lifecycle support https://github.com/npm/npm/commit/c8e17cef720875c1f7cea1b49b... on 1 Mar 2010
and later extend to run arbitrary targets https://github.com/npm/npm/commit/9b8c0cf87a9d4ef560e17e060f... on 13 Dec 2010
This is the entire design backstory https://github.com/npm/npm/issues/298 .
Needless to say that GNU Make’s equivalent (or any other build system) is not to be found in npm’s scripts.
The Makefile is the facade to the project. So you can have `make run` do `make run-windows` or `make run-nix` under the hood. And when you change hosts, or you redo the `run-X` targets into a single cross-platform binary or you put it in a Docker container, nothing changes. You don't need to remember that you need to invoke X or Y script.
I'm pretty sure git-bash provides `Make` on Windows. I believe thats how I tested it for this project: https://github.com/J-Swift/cod-stats