feat: add dal_alight backend — autocomplete-light web component alternative to Select2

[PurpleToti]

Summary

This PR introduces dal_alight, a new backend for django-autocomplete-light that replaces Select2 with the autocomplete-light vanilla web component.

• New app dal_alight with full parity to dal_select2: queryset views, grouped views, queryset-sequence, GenericForeignKey, Taggit, create_field, forwarding, list choices, and nested inline admin popups.
• Test coverage: unit tests (test_units.py) and a full suite of Splinter/Selenium functional tests mirroring every select2_* test app — all passing in CI.
• Documentation: new docs/alight.rst tutorial, docs/backends.rst comparison page (feature matrix, when-to-use, known gaps), and docs/index.rst entry.
• No breaking changes: all existing dal_select2 tests and apps are untouched; the existing dal-django.js helper is now vendored in-tree (moved out of the submodule).

Test plan

• cd test_project && pytest -v --liveserver 127.0.0.1:9999 — all dal_alight unit tests pass
• BROWSER=firefox MOZ_HEADLESS=1 pytest -v -k alight — all functional tests pass headless
• cd docs && make html — docs build without Sphinx warnings
• Existing select2 tests unchanged

🤖 Generated with Claude Code

[jpic]

Can we render a django forms Input widget inside here instead of hard-coding the input HTML?
Wondering if this could allow the user to customize the input widget, including the placeholder which needs to be translated, if possible, find a string that's already translated in Django itself so that we wouldn't have to maintain translations here

[PurpleToti]

Done. Now uses forms.TextInput(attrs={…}) rendered via input_widget.render(…, renderer=renderer). Placeholder is gettext_lazy('Search') — 'Search' is already present in Django's own admin translations, so no new strings to maintain.

[jpic]

Not convinced by this class, what other options do we have?

[PurpleToti]

AlightInitialRenderMixin is gone. Its logic (narrowing the queryset to current values on render so only relevant <option> elements are emitted) was merged directly into AlightWidgetMixin.render(), guarded by a _narrow_choices_on_render flag. The flag is True only on ModelAlight and ModelAlightMultiple — this prevents GFK widgets (which use composite 'content_type_id-object_pk' values) from having their queryset filtered with those strings, which would crash. The mixin class is deleted.

[jpic]

Excellent work really.

But I need some of the code to move to be in order:

Select2InitialRenderingMixin -> I don't see anything that is specific to select2 here, as such, I believe this code should be in the global WidgetMixin, sorry I didn't note that when I reviewed 9eabac0 I guess I was so happy we didn't merge the ast eval ...

As such, AlightWidgetMixin need a diet, because it also contains almost the same code as in Select2InitialRenderingMixin. All at logic about choices rendering is the responsibility of WidgetMixin, because it is generic and needed to make an autocomplete widget no matter what the backend is.

• dal -> contains code generic to making an autocompolete in django
• dal_select2 -> goes on top of that and adds select2-specific code
• dal_alight -> goes on top of that and adds alight-specific code

Feel free to add extra methods in WidgetMixin so that they can be overridden by their select2 and alight counterparts though.

[jpic]

Also, I see the same code in dal_select2.fields and dal_alight.fields, as such, that code must move into dal/fields.py and be shared by both implementations

[jpic]

Do we really still need that ? I thought the AlightWidget would return the HTML with the component in its render() override

[PurpleToti]

Agreed — removed. The if getattr(self, 'component', None) wrapping block and the component = 'autocomplete-select' class attribute have been removed. AlightWidgetMixin.render() now owns the full assembly: calls render_forward_conf() directly and returns mark_safe('<autocomplete-select>…</autocomplete-select>') with the forward conf div inside (required since dal-django.js queries .dal-forward-conf within the wrapper).

[jpic]

Can't we add that in the web component?

[PurpleToti]

Done, with a small architectural note. Rather than patching AutocompleteSelectInput.prototype.url from outside (fragile — depends on property descriptor internals and whenDefined timing), dal-django.js now registers window.AutocompleteLightBuildForward = buildForward. The url getter in AutocompleteSelectInput calls this hook fresh on every request, appending &forward=… if the hook is present. This gives the component full ownership of URL construction while keeping the Django-specific forward logic in dal-django.js. A data-forward attribute approach was also tried but failed for dynamically-added inline rows (stale between events).

[PurpleToti]

same code in dal_select2.fields and dal_alight.fields, move it to dal/fields.py

Done. `ListChoiceField` and `ListCreateChoiceField` (including the `validate()` override that skips `ChoiceField.validate` for newly-created values) now live in `dal/fields.py`. Both `dal_alight/fields.py` and `dal_select2/fields.py` are thin pass-subclasses: `class AlightListChoiceField(ListChoiceField): pass` etc.

[PurpleToti]

Select2InitialRenderingMixin → WidgetMixin / AlightWidgetMixin needs a diet

Done. `Select2InitialRenderingMixin` has been absorbed — `WidgetMixin` now owns `filter_choices_to_render()` and `optgroups()`, and `QuerySetSelectMixin` overrides `filter_choices_to_render()` for queryset-backed widgets. `AlightInitialRenderMixin` was deleted entirely; its logic flows through the base `WidgetMixin.optgroups()`. Additionally, `AlightWidgetMixin` no longer holds the outer `` wrapping via a `component` attribute — `WidgetMixin.render()` has been cleaned of that logic, and `AlightWidgetMixin.render()` now owns the complete assembly including `render_forward_conf()`.