fix: switch back from esm to cjs / provide cjs fallback

[kiprasmel]

We want to use this package together w/ tsc and sometimes with ts-node[-dev] as well.

We've been debugging various issues when trying to implement this, and
the only thing that helped was using cjs instead of esm.

Currently we have [1] a fork of this repo as a git submodule, with the
submitted PRs implemented in a separate branch, and use that directly
instead of an npm package - it works great, but this is far from ideal
and going back to cjs / using it in general means better compatibility
for all of your consumers - both those using cjs and esm.
This does not apply the other way around, and that's why it's an
issue for us that this package is with esm.

[1] https://github.com/kiprasmel/using-fs-xattr-with-ts

If this deems unacceptible, could you keep the things as-is,
but also create a separate file that uses cjs
which we could import from the npm package
something similar to this:

import { getAttribute } from "xattr/cjs"

or similar?

---

see also:
https://twitter.com/Rich_Harris/status/1441068317930819589

[LinusU]

From the Tweet you linked:

consequence: ESM will take over faster than you expect. slowly at first then all at once

the only rational response is to get ahead of it: start new projects with {"type":"module"} in your package.json.

😄

I am not interested in adding back CommonJS support since I believe that the entire ecosystem is moving to ESM. If you cannot upgrade to ESM right now, I would recommend using version 0.3.0. The only difference between 0.3 and 0.4 is ESM support.

That being said, you should be able to use this package with tsc and ts-node. It seems like ts-node-dev still lacks support, but nodemon can do the job there until support has landed.

I submitted a PR to your repository here which demonstrates that: https://github.com/kiprasmel/using-fs-xattr-with-ts/pull/1

[mo22]

typescript's esm support is all but stable, barely usable at most, so providing a cjs fallback would be appreciated