What an ambitious project, I love it.
> Longer-term, bun intends to replace Node.js, Webpack, Babel, yarn, and PostCSS (in production).
https://github.com/Jarred-Sumner/bun#limitations--intended-u...
> Longer-term, bun intends to replace Node.js, Webpack, Babel, yarn, and PostCSS (in production).
https://github.com/Jarred-Sumner/bun#limitations--intended-u...
> Rome is a formatter, linter, bundler, and more for JavaScript, TypeScript, JSON, HTML, Markdown, and CSS.
> Rome is designed to replace Babel, ESLint, webpack, Prettier, Jest, and others.
Haven't seen it since.
> Parcel: The zero configuration build tool for JavaScript, CSS, HTML, TypeScript, React, images, SASS, SVG, Vue, libraries, Less, CoffeeScript, Node, Stylus, Pug, Electron, Elm, WebGL, extensions, GraphQL, MD
As long as you do the bare minimum for each target.
Normally I start with something else (webpack, rollup, whatever happened to be there with the example I'm starting from), then when I hit some roadblocks I just parcel index.html and I have something working.
Something has done a bit wrong if you're running any of those tools in production.
Most companies have things that run "in dev", "in staging", "in CI", and "in production". These map directly to some tools - for example, React has "development" and "production" modes. When someone says a server or a database or a tool is used "in production" they're usually referring to the live environment that users access. Most people use tools like Webpack locally to run code when they're doing dev work, and in CI to build things. If someone said to me "We're running Webpack in production" then I would have questions.
If you use "in production" to mean "anywhere in a project", then how do you differentiate between a staging environment and a production environment? Do you talk about "the staging environment that's in production"? That would be confusing...