-
Notifications
You must be signed in to change notification settings - Fork 2
Simple esm dist output #3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
…ified pure ESM format.
…in Node, remove and replace microbundle build with tsc, update tsconfigs so that we output only JS modules (ESM), add a dev script for building in watch mode, add DOM lib for missing WebAssembly types in test file, remove unnecessary stuff from .gitignore, use only main and types package.json fields to specify the main export and types (all other imports into dist/ will have type definitions as expected), update README
This change makes the project easily consumable in the vast majority of TypeScript projects because it follows the simplest possible project and output layout. In this format, most projects, tools, and even browser applications, will have the easiest time trying to import the library with the least amount of configuration, including with type support.
By dropping microbundle we also dropped support for UMD, CommonJS, and multiple variations of ES modules. It is better to start with something simple that works, then if we want a UMD build we can add that, but we definitely don't need a CJS build. On with the ESM future!
BREAKING: `import { w } from 'wazum'` no longer works. The minimal upgrade path is to use `import * as w from 'wazum'`. The new format is friendlier for anyone who has ESM-based tree shaking in their build setup; importing in the form `import { Module, add } from 'wazum'` will have better tree shaking support with today's tools.
|
Hi again, thanks so much for contributing! @trusktr If you don't mind, I'll go over everything closer to the end of the week, as I am a little swamped right now! After briefly going over the changes right now, one comment I have so far is that I believe it's best to keep this namespaced import syntax, as it works best with intellisense and aligns with modern tools like zod: import { w } from "wazum"Additionally, if anyone would like to opt out of the import { local, ... } from "wazum/w"I don't remember if I already implemented the above, yet |
|
Interesting, what editor are you using? In VS Code, I was getting no intellisense (mainly because of the non-idiomatic output format of microbundle, and I've had these issues with other libs that follow Preact's bespoke packaging patterns too), but after this change, I have full intellisense. Have you tried Perhaps we can have a call sometime and we can share screens to figure out how it currently works on your side. I can go ahead and implement a single |
|
Yeah tree-shaking is a good point, although not sure if it's even worth considering given the tiny size of the library and that probably a big chunk of it will always need to be imported by the user. I was able to reproduce that the imports are in fact really broken. But it has definitely worked before. Working on this. |
|
We can add This is the simplest ESM setup. I use a setup like this for all my libs, and it avoids having issues with, for example, setups using Vite, Parcel, Webpack, Rollup, unpkg, skypack, jspm.io, Node ESM, browser ESM, etc. The simpler and the more aligned with vanilla ESM standard we stay, the easier it will be to maintain and the more likely it'll work everywhere. Microbundle aims to satisfy the global script and archaic requirejs AMD module use cases with the UMD bundle. So another question is, do we want to support global script tag usage, f.e. <!-- Someone with no build can import it like this in a browser: -->
<script type="importmap">
{ "imports": { "wazum": "/node_modules/wazum/dist/index.js" } }
</script>
<script type="module">
import * as w from 'wazum'
// ...
</script>Someone who uses requirejs can easily still set up a native I recommend just keeping it simple, essentially everyone today can consume a vanilla ESM layout. Plus someone using an ancient version of Node can easily install Rollup, and build a (CJS or ESM) bundle out of |
Fixes #2
The commits have all the details. TLDR: simple ESM output compatible with most tools of today, type definitions just work.
Breaking change:
This can be tested by installing my fork from git:
npm install 'wazum@trusktr/wazum#simple-esm-dist-output'Note that the new
preparescript added to package.json is what allows install from git to be possible (when using npm). Npm will install devDependencies locally, run the prepare script, then package the library after the prepare script has finished. Note that this may not work withyarnorpnpmbecause they don't follow (last I checked) this part of NPM spec.