Skip to content

Conversation

@trusktr
Copy link

@trusktr trusktr commented Jun 5, 2023

Fixes #2

The commits have all the details. TLDR: simple ESM output compatible with most tools of today, type definitions just work.

Breaking change:

import {w} from 'wazum' // before
import * as w from 'wazum' // now

This can be tested by installing my fork from git:

npm install 'wazum@trusktr/wazum#simple-esm-dist-output'

Note that the new prepare script 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 with yarn or pnpm because they don't follow (last I checked) this part of NPM spec.

trusktr added 5 commits June 4, 2023 15:28
…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.
@judehunter
Copy link
Owner

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 w namespace, I foresaw this solution:

import { local, ... } from "wazum/w"

I don't remember if I already implemented the above, yet

@trusktr
Copy link
Author

trusktr commented Jun 10, 2023

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 import * as w? Only thing you won't be able to do is type "w" and auto import it, but after you add that import statement, the rest should be the same.

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 w export variable if you'd like, and this will have the additional auto-importability, but we will be lose tree shakability that various build tools offer (they statically analyze imports/exports). Hmm, well, if someone avoids the added w variable, they'd be able to regain tree shakability. Your call here. :)

@judehunter
Copy link
Owner

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.

@trusktr
Copy link
Author

trusktr commented Jun 16, 2023

We can add export * as w from ... to explicitly define the importable w variable. True, maybe tree shaking isn't a big deal in this case.

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. <script src="the/lib.js">? My thought is no, with simple ESM format, the following is easy enough, and less to maintain on the library end (one library format usable by everyone):

<!-- 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 import (like above) in their HTML, and expose the variable as a requirejs AMD module if they really want (still with no build tool). Its been a long time since I've seen AMD modules.

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 wazum/dist/index.js, or they can even install the old esm package and simply import it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Current Node ESM format is not easily importable into TS projects with the current exports field

2 participants