Refactor repo

[jawj]

This PR makes some major changes, reorganising the repo into a more normal shape.

• All source code is now found in src (previously most of it was split between export and shims)
• Temporary build artefacts are in build, which is not committed to the repo
• There's only one package.json, and it lives in the root folder
• All built and bundled code that makes up the npm and JSR packages also lives in the root folder
• The above makes it possible to npm install a specific commit or branch without special support.
• Publishing to both npm and JSR is automated, with appropriate checks: just run npm version [patch|minor|major]

Note: I will make a follow-up PR to add printWidth: 100 to .prettierrc.

[amitdahan]

This seems like a compilation output, I thought we're removing those from being committed in this PR?

[jawj]

Right, and in an earlier .gitignore commit I did remove all build output. But then I thought: it's actually extremely useful to be able to npm install whichever commit or branch for testing and support purposes, right? @pffigueiredo even added a setup-release-branch.sh script to make this possible for specific commits, but that's no longer needed as long as we include the build output in the repo.

So — I put back the 4 index.* files that make up the exported package code. I also added a git pre-commit hook script to ensure that these files are up to date prior to any commit.

What do you think?

[amitdahan]

Well there's 2 subjects here :)

• The fact committing build output can be convenient because git essentially contains a superset of the NPM published package

  I guess it really can be convenient, but per-commit previews can be achieved by other means (definitely a lot more work though). One benefit to "doing it properly" is that installing a commit preview can be more similar to the eventually installed NPM tarball (for example some files may be excluded according to package.json but a commit preview with committed build output would still work)
  It's a trade-off, personally I'd pick having a cleaner git flow (without build output), and risk complicating a commit preview setup.

• Whether a pre-commit is used to ensure it's up to date, instead of a CI check

  I really hate pre-commit hooks :D I'd always choose a CI check to VERIFY, and leave the responsibility of passing requirements to devs. I think commit/push hooks should never serve as a way to conform to something, only as a convenience factor (that can be opted in/out of, so optional).

---

Anyway just my own preference, it's a trade-off and it's ok if we just go with it.

[jawj]

I like the pre-commit hook for my own use (I've lost count of how many times I committed code that failed format checks!), but I agree we can't enforce that.

So I guess we could also check in CI that the built files are all up to date?

[amitdahan]

lgtm! let's wait for @pffigueiredo 's review too since this is a big change

[pffigueiredo]

I'm not the biggest fan of having index.d.mts and related right in the root folder, but it's also not something I'm willing to die on a hill for 👍