-
-
turbo
Incremental bundler and build system optimized for JavaScript and TypeScript, written in Rust – including Turbopack and Turborepo.
-
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.
-
-
-
-
-
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.
-
-
salsa
A generic framework for on-demand, incrementalized computation. Inspired by adapton, glimmer, and rustc's query system.
-
-
MAL-Cover-CSS
Automatically generate CSS to add cover images to your MyAnimeList classic list designs
Getting Next.js up to Rails feature-wise is using something that already wires up the niceties like Auth and ORM. Create-t3-app is a huge contender here: https://init.tips/ and https://github.com/t3-oss/create-t3-app
A DB is as simple as pressing a button on Planetscale or Railway, copying the secret strings to your .env file, and npx prisma db push.
Right, they link to this docs page when referring to the memoization library: https://turbo.build/pack/docs/core-concepts
And the github link at the top of the page links here: https://github.com/vercel/turbo but, despite being called "turbo", that seems to actually be the repo for Turbopack (the webpack alternative) not "Turbo" the library.
Even digging a bit into the crates, I'm not sure where this supposed library lives: https://github.com/vercel/turbo/tree/main/crates
I think this might have just made their lives easier, from the projects website:
> Rome is designed to replace Babel, ESLint, webpack, Prettier, Jest, and others.
Since both projects are written in Rust, the Rome team could use Tubopack to build/bundle projects and focus on the other features they are planing: https://rome.tools/#supported-features
esbuild is great, but our only blocker for using it was that there was no way to control the number of chunks. On a moderately sized modular app, this can slow down things significantly[0]
[0] https://github.com/evanw/esbuild/issues/2317
After years of configuring webpack for various projects I have finally decided to migrate all my projects to Parcel[1] manly because I got tired of creating and maintaining hundreds of lines of webpack.config.js files, I wanted something that just works. I am really happy with that decision.
Parcel is plenty fast and is pretty much zero config, I can use it to build libraries[2] as well as applications[3] for the browser and node.
I am manly building client side react applications, so your mileage may vary.
[1] https://parceljs.org/
[2] https://parceljs.org/getting-started/library/
[3] https://parceljs.org/getting-started/webapp/
You can try hel-micro(https://github.com/tnfe/hel) A runtime module federation SDK which is unrelated to tool chain，It means that any tool system can access module federation technology in seconds ， Users do not need to be bound to the webpack system。
Bazel is just the infrastructure to run webpack. You'd need to do some work to make webpack's state be cacheable (I dunno what options and such it has for this, maybe it's already there as an option). But if you're looking at Bazel for JS work you probably just want to use the existing and maintained rules for it: https://github.com/bazelbuild/rules_nodejs It's been a while since I last looked at it but I don't think it has any caching for webpack.
Stable API perhaps, but vite has issues with memory leaks, which can break builds in CI.
https://github.com/vitejs/vite/issues/2433
> special snowflake build toolchains
That reminds me, wasn't there a build tool called Snowflake?
Oh, it was called Snowpack [1]. And it's no longer being actively maintained. Yeesh.
[1]: https://www.snowpack.dev/
The content of that "Core Concepts" page sounds a lot like https://github.com/salsa-rs/salsa
The Rails https://github.com/rails/jsbundling-rails gem lets you pick between esbuild, rollup and Webpack. If Turbopack ends up being popular then jsbundling should be able to support it.
The nice thing about Rails now is there's no direct integration like Webpacker once was. Now we can basically use the JS tool straight up and Rails will just look at assets in a specific directory, it doesn't matter what tool generated it.
You can cut down the duplicate config with webpack-merge package. I start with a common config object that defines loaders, aliases, etc. and it gets imported by my frontend/backend/cronjob/worker targets that simply describe the entry/outputs
I also recommend using ts-node and write your configs in Typescript to avoid typos
Here's an old side project of mine that has 3 targets [1]. I personally don't think it's that complex but it does have hundreds of lines altogether.
[1] https://github.com/Trinovantes/MAL-Cover-CSS/tree/master/bui...
> I’m still searching for a zero-conf full-stack pipeline which could manage both frontend and backend in a single project under a single watch command
I did create a proof of concept how this could be done in parcel https://github.com/mochicode/parcel-fullstack-poc.
The /src folder contains:
1. /api => backend
2. /app => react frontend
3. /shared => shared code
Once everything is installed, just run "npm start" and it will:
1. build and watch your src folder
2. react hmr/fast-refresh works
3. nodemon will reload your node server when things change
Not zero-config, but it almost gets you there.