Remaining work on packaging for publish.

[chrisdevereux]

Description

This PR:

• Adds CI hooks to build & publish to npm/pypi when a GitHub release is created.
• Pre-builds static assets into the pypi package before release (usable without a frontend build toolchain).
• Builds an esmodule version for npm (usable by frontend bundlers).
• Builds d.ts files for npm
• Drop typescript path aliases because they were interfering with d.ts file generation
• Switch out ts-jest for babel-jest because it didn't play nicely with some newer js features vite supports (import.meta)
• Renames pyck -> groundwork
• Adds a template tag for django to load assets in environments without a frontend build toolchain.

Motivation and Context

This library needs publishing before people can use it!

Was unsure about whether to tackle this now or defer it, but it'd be quite annoying to use without doing so – the npm package needs building before install and in practice so does the python package, as it includes a bunch of static js and css.

How Can It Be Tested?

• Test deployment to npm
• Test deployment to pypi

Hard to fully test yourself because it involves a release hook on CI. I have done by temporarily switching the CI trigger to pull-request and running it on this.

Types of changes

• Tooling change

Checklist:

• I have documented all new methods using google docstring format.
• I have added type annotations to any public API methods.
• I have updated any relevant high-level documentation.
• I have added a usage example to the example app if relevant.
• I have written tests covering all new changes.

[conatus]

@chrisdevereux

Do you want this reviewed now? I am presuming you do not right this moment, but do request my review when you want it looked at.

[chrisdevereux]

@conatus Sorry, missed that. No, I did not. Now I do!

[janbaykara]

Not seeing anything wildly wrong here.

Occurred to me that there could be scope for including a django variant of Ruby-style import maps, for loading Stimulus controller files for templates, as an alternative to bundling them altogether.

Glad to see this publish soon!

[janbaykara]

Maybe repeat the package slug groundwork-django here, for easy copy pasta? This could also be echoed in README.md. I note that groundwork is actually taken by another package, but that would have been my immediate guess.

[chrisdevereux]

Good call. Updated.

[chrisdevereux]

Not seeing anything wildly wrong here.

Occurred to me that there could be scope for including a django variant of Ruby-style import maps, for loading Stimulus controller files for templates, as an alternative to bundling them altogether.

We in fact kind of already have this behaviour by using dynamic import() to load and register controllers on-demand

This is also exposed as a utility to the application, which it can use to load its own controllers, and does by default in the starter template. It should be better documented though! In general, I haven't written anything on the stimulus side of the library. I'll make a task to do that.

Using import maps could prove to be a more 'standard' way of providing this behaviour when the django hotwired libraries mature a bit. This is nice in that it doesn't impose any constraints on how the django app is configured though.