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

[trusktr]

I know how to make this work well, I've too much experience with Node ESM.

These are the issues I can help work through:

Do you have any downstream projects that import wazum in its current state? If so, I'd like to take a look at those too so I know how to make the changes. The reason I ask is because in modern times, there isn't really a need to support old formats like UMD, etc. We can start fresh. Modern packages only need to publish ESM, and new projects should adapt. (IMO). But if you require support for old environments, it will be more maintenance burden (and issues).

This will be a bit of a change, will change the build and the output files completely, so that they are as idiomatic as possible (as close to regular vanilla ES as possible).

[judehunter]

Hi @trusktr, thanks for your interest! I guess I haven't touched this project for a while..
The main consumer of this library was supposed to be queso, a programming language I made -- once wazum is somewhat complete. But wasm and compilers are just a hobby for me, so I work on it very occassionally :)
Unless of course, many were looking to use wazum in their projects, in which case I would keep working on it. But that doesn't really appear to be the case, currently. Are you looking to use it yourself?

In terms of ESM, I have doubts about not needing to support old formats.. maybe I'm just used to it. But I think the issues you've shown can be fixed without disabling multi-format bundling?

[trusktr]

Are you looking to use it yourself?

Yeah! I started a new project to compile TS to Wasm (not revealed yet, but DM me and I can share it).

I tried Binaryen.js, and I really disliked how every parameter or return type is just number; truly not helpful.

I searched for "alternative to binaryen", and Wazum was among the first results (article you wrote), and there wasn't really anything else.

I immediately loved the well-typed and well-documented interfaces you have. So good! 👏

setTimeout(function go() {
  clap.click()
  setTimeout(go, 10)
})

But I think the issues you've shown can be fixed without disabling multi-format bundling?

They probably can but with more work. The microbundle configless approach is proving to not be flexible for this, and we'll need to use something configurable (Rollup would be good) to make the output mode ideal.

Here's what I did to get it working well:

#3

The approach was to simply map the .ts files to .js files in dist.

Further work can be to make a unit test for in a browser (I really like @web/test-runner, the easiest-to-use browser unit test runner I've come across so far, way easier to use than Karma), to show what it would be like to import the ES modules in a browser.

With this change, the lib is now easily usable with type defs detected well:

CommonJS or browser users can import() or import the files, respectively; we can add unit tests for this too.

Someone who has a really old environment can easily make an entry point, and compile a bundle with Rollup, then put that bundle in their project. I think its no big deal. Better to keep it simple with modern standards.

The structure that will get published to npm will now be this:

❯ tree
.
├── LICENSE
├── README.md
├── dist
│   ├── compiler.d.ts
│   ├── compiler.js
│   ├── index.d.ts
│   ├── index.js
│   ├── methods.d.ts
│   ├── methods.js
│   ├── module.d.ts
│   ├── module.js
│   ├── nodes.d.ts
│   ├── nodes.js
│   ├── utils.d.ts
│   └── utils.js
└── package.json

with package.json main/types pointing to dist/index.js/dist/index.d.ts.

Avoiding the exports field makes the project be closer to vanilla ES Module spec. The more vanilla it is, the likelier it is to work with most tools (including tools like unpkg.com that ignore the exports field, so we get essentially the same usage in Node as in the browser, rather than different approaches of importing in either or).