npm-package-ts-scaffolding VS typescript-esm-packager

This is a zero dependency package that provides some expirable implementations of common Data Structures. Thanks to the npm-package-ts-scaffolding it is importable both via CommonJS and ES Modules. It currently supports the following Data Structures:

So there you have it: npm-package-ts-scaffolding

The rumors are true! Luxury housing is in development, and it’s taking place in Hell’s most gentrified neighborhood. Sources close to the project are calling it ES Modules, and everybody who’s anybody wants in on this high-end horror show.

Honestly, I love the new module syntax compared to the old `require` song and dance. They fit nicely with promises and ensure some level of behavioral consistency in the browser and other runtimes. We could even drop the need for bundling for small enough projects, and get back to the simpler times of dropping a script tag in your HTML. I just don’t understand why Node can’t get its story straight.

Let’s just talk about the file extension thing first. The brain trust at the lab decided that ES module files should have a .mjs extension to indicate the contents of the file. Fair enough. But .js also works sometimes, depending on the configuration set in the package.json file? We’ll chock this up to gradual adoption.

There’s also some fun caveats about module resolution to keep things interesting. ES Modules need either a fully qualified path, or a relative path — both must include file extensions. Again, that’s also fine. I actually prefer it! So there’s the mystery factor of what happens to all the current NPM packages that aren’t compliant. Simple! We just have a special flag to make those work.

So how do we get this ball of tape running in the browser exactly? A bundler…the very thing we were trying to avoid in the first place! Remember the dream of isomorphic code? Not debugging a Webpack build with shoddy source maps? We’re right back where we started but with a whole new set of meta problems.

The most entertaining part of this game is telling your coworkers the difference between an import map and a package.json exports declaration. God help you if have TypeScript holding up this paper shack. Try building a ES module compatible library that includes TSX files just using the TypeScript compiler. Remember that it’s gotta be .mjs files that get output, and all your imports have to be fully qualified.

If you’re nostalgic for the DMV, I recommend that you visit the TypeScript repo and check out how this module thing is going. You see, there are two developers at Microsoft. One tells truths, and the other plugs their ears and shouts, “LALALALALALA! TypeScript doesn’t and won’t ever rewrite modules!”

It’s been like this for years and will take some additional years to complete. And don’t get me wrong, I’m sympathetic to the difficulties of this affair. But it’s becoming more like a sudden urge to vomit when the someone in the room starts heaving at your table.

And finally, I’m so spoiled that I expect free stuff from the community. I built a tool to make ES modules and TypeScript play nice. It’s my greatest wish that it gets deprecated before I’m sent to live on a farm upstate…

https://github.com/sister-software/typescript-esm-packager