-
Notifications
You must be signed in to change notification settings - Fork 43
htmx extension without globals #38
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
@silverwind I like the idea in theory! However, the reality of the current state of the JS module system is that its a paralyzing mess. We are currently supporting several different ways of combining source files: server-side bundlers, client-side importmaps, ESM, CJS, AMD, and That said, I'm open to any proposal you might put forward to address the issue you raise, without breaking compatibility for other inclusion methods. Got any ideas? |
I would consider going pure ES modules and deprecating the other module systems at some point. Every major browser released since around 2020 supports ES modules. See https://caniuse.com/es6-module. The vite bundler defaults to this as well via its default |
@silverwind Just an update here. We're getting ready to release v0.5.0, which adds the Additionally, I would love to deprecate (or remove entirely) some of the older targets, as you suggest. Let's look into that as well. |
@silverwind https://www.npmjs.com/package/idiomorph/v/0.7.2 should resolve this. You can import "idiomorph/htmx" now, which give you an Idiomorph that is already registered with htmx as an extension. |
The htmx init code here relies on a
htmx
global:idiomorph/src/idiomorph-htmx.js
Line 12 in 8e40c42
While reliance on globals is probably okay with
<script>
usage, in a scenario with a bundler it is not necessary and undesired to have any globals. How about allowing something like this?Related: bigskysoftware/htmx-extensions#128
The text was updated successfully, but these errors were encountered: