Microbundle VS webpack

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

Build it with https://github.com/developit/microbundle and save yourself hours of build tooling setup.

Online, on the other hand, the few guides I did find for instance in the microbundle issues have a structure like this:

Since I'm still new to SvelteKit and Vite, though, I still have to figure out the best way to package it for production use, and am coming back to you guys for some tips. Someone recommended I check out microbundle last time around, which I will definitely do, but I'm also curious on other build pipelines, since the one I have right now doesn't really play nice with Vite.

Checkout microbundle. It offers zero-config support for TypeScript, and produces ESM, CJS, UMD, etc.

I don't know how you do the build of your GUI or perhaps you haven't thought of that yet. If the latter then that is something to think about but not an absolute requirement. You could for example use Webpack.

const path = require("path"); const webpack = require("webpack"); const HtmlWebpackPlugin = require("html-webpack-plugin"); const HtmlBeautifierPlugin = require("html-beautifier-webpack-plugin"); module.exports = { mode: "development", entry: "./target/index.js", output: { path: path.resolve(__dirname, "public"), filename: "js/libs/bundle.js", clean: false, }, devtool: "source-map", module: { rules: [ { // docs: https://webpack.js.org/configuration/module/#resolvefullyspecified test: /\.m?js/, resolve: { fullySpecified: false, alias: { models: "../src/amplify/models/index.js", "ui-components": "../src/amplify/ui-components", }, }, }, { test: /\.jsx$/, exclude: /node_modules/, use: ["babel-loader"], }, ], }, resolve: { extensions: ["", ".js", ".jsx"], }, plugins: [ new webpack.ProvidePlugin({ process: "process/browser", }), new HtmlWebpackPlugin({ template: "./public/index.html.tmpl", filename: "index.html", }), new HtmlBeautifierPlugin(), ], };

When your module bundler (I'm using Webpack for this example) encounters a dynamic import, it bundles the module as a separate file.

I've used webpack before for bundling, and while it is a mature and flexible bundler, you may run into problems with its memory usage and execution when you use it on very large projects with dozens of AWS Lambda functions. This is because it is written in JavaScript and must execute the same bundling process for each Lambda function.

Note that generating CJS output with named exports from ESM is not currently possible with Webpack (support is pending Webpack PR#14998); it's not possible with esbuild (which, like Webpack, produces a non-static exports). However, Rollup DOES produce compatible output; the working example below uses Rollup instead of Webpack.

That much is pretty easy, the hard part is deep diving into bundlers like Webpack, which make modular programming in Javascript possible. Create React App hides some of the complexity and lets you get started writing a React app quickly, but if you're not using CRA then learning about bundling and transpiling can send you down a pretty deep rabbit hole of topics to learn.

Create React App (CRA): This is a library that I have used previously for other games/projects, this is an easy starting point for a react project because we have all our environment configured, for example, we have webpack, hot reloading, service workers (via workbox) and other features ready to be used, for this type of project I think is the best way to learn React.

At the time I had been exploring alternatives to Webpack like fuse-box, parcel, and esbuild. Around the same time I was made aware aware that browsers had already implemented [ESM modules], so technically as long as you produced HTML, CSS, and JS you didn't need any kind of pre-processing at all.