Minified Build Support

[Offroaders123]

I've been curious about looking into using esbuild instead of tsc to compile the source for use in Node and the browser. Things are still a little over my head in terms of implementing it nicely in conjunction with my existing tsconfig.json settings, so I'm going to wait before committing things yet. There were a bunch of resources I found while trying to look into this, but it's still just a little over my head which route is the right way to go for NBTify.

I think my trouble is that I want to allow for multiple different ways to be able to import NBTify. In the browser, I'd like to have a fully ESM-compatible bundled build (minified, with dependencies), where you can still do (essentially) import { feature } from "https://cdn.dev/nbtify". I also want a fully-ESM compatible non-bundled (dependency-wise), maybe minified, build for Node.js (not in CommonJS). I think my current hangup is whether or not the Node.js build should be minified, as it sounds like it's less helpful for tree-shaking when used with a bundler (since you would want to import the Node ESM version when used with something like Vite, rather than the one that already has the dependencies bundled in, as for the CDN ESM build). And for another part of this, how does this all work with that I also have a CLI script for NBTify, as well as needing to use tsc to provide type definitions for the library as a whole, for any of these combinations?

So maybe it's not that the setup for it is very hard, but that I haven't fully decided yet as to which is the best way to target each of these use-cases.

And yeah, what's the proper way to manage your "bin": "./dist/bin/index.js" setup, in conjunction with regular-old library exports? What folder structure do people usually use for that? And are these two separate esbuild entry points?

Should I still provide a CommonJS-specific build output? Or is it encourage towards moving away from the dual-package setup, for new packages? I haven't personally had really any issues with needing to use NBTify in CommonJS thus far, but maybe someone else needs it for something, and they don't want to/can't migrate to ESM yet. I'd like to be able to make NBTify work for them, rather than have them need to figure out all of this on their own. Using ESM in the Electron backend is a valid issue, but I think that sounds to be less of an issue as of the last year or two, since it supports ESM now.

Lots of links related to this one

https://souporserious.com/bundling-typescript-with-esbuild-for-npm/ https://github.com/souporserious/bundling-typescript-with-esbuild-for-npm https://esbuild.github.io/getting-started/#build-scripts https://esbuild.github.io/api/#outbase https://bundlephobia.com/package/[email protected] (Seems to be fairly similar in size to what esbuild does in my current demos for this) https://nodejs.org/api/packages.html#--input-type-flag (New find, didn't know -e had a flag for this! Awesome) https://medium.com/outbrain-engineering/the-hidden-power-of-package-json-a93143ec0b7c (https://github.com/sciencesakura/mutf-8/pull/17) https://dev.to/andreasbergstrom/simplify-typescript-builds-with-esbuild-and-skip-tsctsx-2124 https://github.com/vitejs/vite/issues/1585 https://news.ycombinator.com/item?id=28861433 https://www.youtube.com/watch?v=mSnDUMybZXk https://blog.logrocket.com/getting-started-esbuild/ https://esbuild.github.io/content-types/#tsconfig-json https://github.com/evanw/esbuild/issues/1343 (I noticed this with TS a while back in setting up a proper ESM build as well, I like that esbuild followed TS with this one. It's the choice to stay consistent, rather than trying to fix things on it's own) https://www.youtube.com/watch?v=z16rzIF5J40 (Unrelated, cool find) https://www.youtube.com/watch?v=alrLzBTHFH8 (current song)