Microbundle VS webpack

For package authoring - microbundle is a handy boilerplate (I would avoid tsdx personally - it’s basically been abandoned for turborepo but that’s not apparent at first glance).

My tech stack was React + Typescript, Storybook for docs, vite.js for build instead of webpack, microbundle for bundling (basically a no-config rollup wrapper), and Google's release please bot for handling release/deployment.

Setting up a modern Typescript or Javascript development stack is a daunting task, there are a lot of moving parts, and sometimes the whole process seems like magic, so I switched to Microbundle. While microbundle handles the compilation, there are a lot of other moving parts that need to be set up to start developing with Nodejs/Typescript (CI, tests, linting, etc). So I've created an opinionated template repository with Typescript, Microbundle, Jest, eslint, husky, prettier, github actions, pnpm, and a bunch of other scripts. It enables me to start developing a library immediately by using the repository as a starter template. Let me know what you think and if some processes could be improved, or some valuable tools that could be added. Pull requests and suggestions are welcomed.

I would recommend starting by using https://github.com/developit/microbundle , as it has pretty good default behavior for generating library output.

Check out microbundle, which is what TSDX started as a typescript alternative to.

I’m quite happy with Microbundle

Pick up Microbundle or something similar.

Lerna Microbundle Next.js

I'm not gonna lie, I didn't read all that, but the node example alone proves you either didn't read the guy you replied to or haven't been coding long enough to grok the problem.

What if you want to start a new project using the latest postgres version because postgres has a new feature that will be handy, but you already maintain another project that uses a postgres feature or relies on behaviour that was removed/changed in the latest version? You're going to set up a whole new VM on the internet to be a staging environment and instead of setting up a testing and deployment pipeline you're going to just FTP / remote-ssh into it and change live code?

you define an apps entire chain of dependencies in a compose file / set of kube manifests / terraform config for ecs. Then in the container definition itself you lock down things like C library and distro versions: maybe you use specially patched imagemagick on one project or a pdf generator on another, and fontconfig defaults were updated and it changed how aliasing works between distro releases and now your fonts are all fugly in generated exports...

nevermind this, check out this thread to destroy your illusion that simply having node installed locally will make your next project super future proof https://github.com/webpack/webpack/issues/14532

if you respond please do not open with "yeah but rust", I can still compile Fortran code too

With tools like webpack (used by create-react-app under the hood), your entire application needs to be bundled in a single file before it can be served to the browser. Vite, on the other hand, takes advantage of native ES modules in the browser to make bundling more efficient with Rollup, serving parts of the source code as needed.

If I choose React as a used framework, Ionic’s boilerplate is based on Create React App. Because of it I want a tool which edits Webpack’s configuration without ejecting CRA’s configuration.

Webpack webpack.js.org

Module Federation is a technology provided by webpack that enables modules to be federated across different origins at runtime. This means that Webpack will simply ignore these modules at build time, expecting them to be available to be fetched across the network at runtime.

Webpack: 4.46.0

Packaging - turning all your code, CSS, assets, etc. into the files you'll actually stick on your host server. e.g. webpack, maybe esbuild, etc..

One of our internal tools at RedBit uses yaml to provide structured data. We chose yaml because it's more human-friendly than json, and the data in question is created and modified by humans during development. Applications need to consume the data as JavaScript objects, so we need to convert it from yaml to json. We could do the conversion at runtime but that would affect performance, possibly to the point of degrading the user experience. Instead, we chose to convert the data during the build process, which is controlled by webpack. This required a custom webpack loader. I won't describe the implementation of our internal tool in detail because it wouldn't be particularly helpful or relevant. Instead, I'll show you how to build a simple yaml loader that you can modify to suit your own needs.

In order to compile the TypeScript code into JavaScript that is supported by modern browsers we will have to install Webpack and bundle the source code into one final JavaScript file that we will later include in our HTML templates.