Adding a @cubing/icons/js entry point.

[lgarron]

@dmint789 is using @cubing/icons with deno server-side. Quoting myself from denoland/deno#27782 :

We published this particular entry point as TypeScript because fantasticon can produce TypeScript output directly but not JavaScript. Since most bundlers can handle that, I wanted to keep it simple and didn't add JS transpilation originally. I will look into the best additional toolchain combinations to publish a JS transpilation so that @dmint789 can use it in their project, but this comes with tradeoffs and for me the whole situation is whatever the opposite of "hassle-free" is. 🙁

The tradeoffs:

• If we transpile JS, we need to generate both .js files and .d.ts files.
• Basically all our projects use esbuild for compilation, but esbuild only transpiles JS and not types.
• esbuild has a nice API inside JavaScript, but TypeScript… doesn't.
• The TypeScript compiler doesn't support type bundling, which means that it would generate multiple files from our entry points and expose internal type names for no good reason.
• tsup is the best option for a standalone type-bundler, but it's rather heavy (32MB across 87 npm packages).

I suspect the least onerous option is to:

• Use TypeScript with the minimal config that we can get working.
• Use it to generate both .js and .d.ts output.
• Invoke the tsc CLI from inside our build script.

I'm going to give that a go.

[lgarron]

Oh, and I forgot: there's a current incompatibility between @types/node and @types/bun that has been unresolved for a long time: oven-sh/bun#8761

We were able to deal with this by just using @types/bun, but now we have a conflict. We can tell TypeScript to ignore that that by setting "skipLibCheck": true, but this can mask other issues down the road.

[dmint789]

So in the end we found out that this had nothing to do with Deno and everything to do with Next JS + Webpack bundling