Extensions don't have UMD wrapper

[xhaggi]

At the moment you need some workarounds to use an extension with Vite, Rollup or other build tools because of a missing UMD wrapper. Furthermore, the extensions are not minified like htmx.js.

Workaround via window

Create a local htmx.js with the following content:

import htmx from 'htmx.org';
window.htmx = htmx;

Import this file before importing an extension.

import './htmx.js';
import 'htmx.org/dist/ext/<extension>.js'

Workaround via rollup-plugin-inject (Vite)

// vite.config.js
import inject from '@rollup/plugin-inject';
import { defineConfig } from 'vite';

export default defineConfig({
  plugins: [
    inject({
       htmx: 'htmx.org'
    }),
  ],
});

[alexpetros]

I'm going to close this issue. If you're already using a bundler then it is not a huge hassle to configure your bundler to import htmx properly. I don't think this is worth polluting the window object in the based htmx for.

I'm open to re-opening it if there's a vocal constituency that feels differently.

[alexpetros]

Re-opening per discussion in #1692

It doesn't feel right to have to use a workaround for importing the htmx extensions properly

Importing htmx extensions into the Vite build system which is not how we recommend installing htmx. I understand that some people do it that way. But in that case they are already using a build system, so the advantage of us having already UMD-ifyed the extension is basically nil, because the purpose of wrapping htmx core in a UMD wrapper is to allow people to import it natively in the browser, no matter which module system they're using.

So from my perspective, if you want to bundle htmx, it's not crazy to ask you to use a plugin that will bundle all that js for you.

[matteocontrini]

which is not how we recommend installing htmx

it's not crazy to ask you to use a plugin that will bundle all that js for you.

I opened the original issue about this problem, and while I don't have a strong opinion on the solutions you're discussing, I don't think it's currently clear enough from the documentation that using npm and a build system is not recommended or has drawbacks.

I think it's a reasonable requirement to have users install that Vite plugin, but if that's the "solution" it should be made more clear in the installation instructions, maybe alongside the existing npm/webpack instructions.

[alexpetros]

Yeah, I use htmx with npm just entirely to serve the dist file, I don't bundle it into anything. I'm open to a docs PR for what you described @matteocontrini.

I'm also open to htmx-side solutions, but speaking for myself, I don't love the two solutions that I've seen so far. Appending htmx to the window (in addition to the document) feels like a weird hack, and wrapping all the extension in a UMD module is clunky. On some level, I'm concerned it's a fools errand to alter the htmx source to meet the demands for various build systems, rather than provide some reasonable common denominator (a JS file) that they can work with.

[xhaggi]

Appending htmx to the window (in addition to the document) feels like a weird hack.

The UMD wrapper does exactly the same when in browser environment and the current documentation https://htmx.org/docs/#webpack pointing you in the same direction.

If you want to use the global htmx variable (recommended), you need to inject it to the window scope:
window.htmx = require('htmx.org');

Of course, my fix is not the perfect solution, but it introduces much less code than any other solution. And I agree, we should update the documentation in this section.

[alexpetros]

Of course, my fix is not the perfect solution, but it introduces much less code than any other solution.

Yes, and I appreciate that!

If you want to use the global htmx variable (recommended), you need to inject it to the window scope:
window.htmx = require('htmx.org');

Don't we basically just need to update this and say "applies to Vite as well"?

[xhaggi]

I don't think that is enough. You have to explain that you need to expose htmx to window before you can import an extension or use the rollup-plugin. All because we don't want to add a single line of code that will fix it.

[anbraten]

Workaround via webpack

// webpack.config.js
import webpack from 'webpack';

/** @type {import("webpack").Configuration} */
export default {
  entry: './src/index.js',
  [...]
+  plugins: [
+    new webpack.ProvidePlugin({
+      htmx: 'htmx.org',
+    }),
+  ],
 };

[danthegoodman1]

I'm running into this as well with vite. I think the easiest solution atm is to just manually copy in the JS and import it. I tried both suggested methods above and as the linked (closed) discussion says I also never see the htmx:afterProcessNode. I only see htmx:beforeProcessNode and htmx:load

[silverwind]

It should be made possible to import htmx in ESM without any globals. It can be done by placing a suitable ESM file in the package and pointing to it in package.json exports, all modern bundlers use that field first when present.

[marisst]

@xhaggi @alexpetros @matteocontrini @anbraten @danthegoodman1 @silverwind
I have created a PR which allows to integrate HTMX extensions as ESM modules using bundlers like Webpack and Rollup. All you have to do is:

import 'htmx.org';
import 'htmx-ext-extension-name'; // Replace `extension-name` with the name of the extension

The way I have implemented it mirrors the deployment of the core HTMX package.

Please check out the PR bigskysoftware/htmx-extensions#123 and hopefully this issue can be closed after it's merged.

@Telroshan this issue should be moved to htmx-extensions repository.