Fix TypeScript types

[nwalters512]

Description

This PR fixes the TypeScript types in src/htmx.d.ts. There were two separate issues:

• Line 432 contained invalid syntax.
• triggerSpecsCache referenced a HtmxTriggerSpecification type the doesn't exist

Given the guidance in #2107 (comment), I opted to remove the types for triggerSpecCache entirely.

Interestingly, there are other parts of the code (JSDoc comments) that reference HtmxTriggerSpecification:

• htmx/src/htmx.js

  Line 1273 in 7f3d114

  * @returns {import("./htmx").HtmxTriggerSpecification[]}

• htmx/src/htmx.js

  Line 1364 in 7f3d114

  * @returns {import("./htmx").HtmxTriggerSpecification[]}

This leads me to believe that this type did exist at one point, but I couldn't immediately find it in the Git history. It seems like a type that should exist though!

Corresponding issue: #2148

Testing

I installed these types into my project and verified that tsc could now successfully parse the types.

Checklist

• I have read the contribution guidelines
• I have targeted this PR against the correct branch (master for website changes, dev for source changes)
• This is either a bugfix, a documentation update, or a new feature that has been explicitly approved via an issue
• I ran the test suite locally (npm run test) and verified that it succeeded

[alexpetros]

We're doing a big re-work for this for htmx 2.0!

[nwalters512]

@alexpetros that's exciting! Is v2 going to be released shortly? The latest version of htmx is unusable in TypeScript projects because of this, so if v2 is not right around the corner, I'd very much like to see this fixed in a v1 release.

[alexpetros]

The beta should be out in a couple weeks.

I'm not sure I agree that htmx is unusable in TypeScript projects, as there are a lot of ways to enable htmx in TS projects that don't require typed DOM attributes or APIs (with templates, for instance). Broadly speaking, htmx enables you to have minimal logic (and therefore minimal scripting) in the frontend, drastically diminishing the need for TypeScript's guarantees to extend past the backend. Many people use statically-typed backends with htmx happily.

I'm sure it's a problem for whatever your rendering setup is, and I apologize for that. I know this response is sort of annoying, but I don't want anyone to find this comment and think it applies to TypeScript projects generally.

[nwalters512]

Sorry, to be clear, I don't mean that it's unusable because of any lack of type declarations or such. I don't actually rely on any of that, and I don't have a "rendering setup" that necessitates any type information from HTMX at all. I love that HTMX lets me avoid a huge amount of scripting on the frontend, and of course I don't require type checking for scripts that don't exist.

I have an import 'htmx.org/dist/htmx.js' statement I use to get HTMX into my client-side bundle; that bundle root is a .ts file. Because of the invalid syntax in the HTMX type declarations, TypeScript errors when typechecking my bundle, even though I don't actually rely on any of HTMX's types:

../../node_modules/htmx.org/dist/htmx.d.ts:432:17 - error TS17020: '?' at the start of a type is not valid TypeScript syntax. Did you mean to write 'boolean | null | undefined'?

432     ignoreTitle:? boolean;
                    ~~~~~~~~~

../../node_modules/htmx.org/dist/htmx.d.ts:438:45 - error TS2304: Cannot find name 'HtmxTriggerSpecification'.

438     triggerSpecsCache?: {[trigger: string]: HtmxTriggerSpecification[]};
                                                ~~~~~~~~~~~~~~~~~~~~~~~~


Found 2 errors.

This isn't silenceable with a // @ts-ignore or a // @ts-expect-error on the import ... statement. So when I say "HTMX is unusable in a TypeScript project", I mean "importing HTMX into a .ts file produces a compiler error that I cannot silence or work around".

I would be equally happy if the fix to #2148 was to remove dist/htmx.d.ts entirely; I had hoped that the PR I opened here would be less controversial and easily merged.

[Fantaztig]

Currently version 1.19.10 is unusable for us as well, we had to manually pin the version to 1.19.9 for now.
We are basically running the same setup as @nwalters512, import htmx from 'htmx.org'; using the events exposed by that.

+1 for this PR as it seems to be the easiest way to resolve this.
I understand you're working on a new major version but I don't see any reason to not merge this trivial PR as upgrading to a new major version is from experience quite a lot of effort usually.

[alexpetros]

Much appreciated on the explanation, I had indeed misunderstood what you were saying. I do think we're going to need to do a 1.9.11, so I'll reopen this and we'll get it looked at.