Is rollup creating an invalid declaration file?

[hazy osprey]

This is my rollup config:

import ts from "rollup-plugin-ts";

const plugins = () => [
  ts({
    transpiler: "typescript"
  })
];

export default [
  {
    input: 'src/index.ts',
    output: {
      format: 'iife',
      file: 'dist/dialog-element-macro.js',
      name: 'DialogElementMacro',
      sourcemap: true,
    },
    plugins: plugins(),
  },
];

This is the output it generates:

var DialogElementMacro = (function (exports) {
  // ...
  exports.closeDialogElement = closeDialogElement;
  exports.openDialogElement = openDialogElement;

  return exports;

})({});

And this is the declaration file it generates:

declare function closeDialogElement(): void;
type TwineScript = string;
declare function openDialogElement(title: TwineScript, classes: string[], content: TwineScript, onOpen?: TwineScript, onClose?: TwineScript): void;
export { closeDialogElement, openDialogElement };

Shouldn't this declaration file define these functions within a DialogElementMacro "namespace?" Pretty much all I want to know so I can troubleshoot from there.

the whole project is here if someone prefers viewing it that way: https://github.com/BawdyInkSlinger/dialog-element-macro

[placid folio]

What does your input file look like?

[hazy osprey]

export { closeDialogElement } from "./dialog-element-close-macro";
export { openDialogElement } from "./dialog-element-macro";

[placid folio]

Looks right to me then.

You're exporting two things and so is the declaration file

[hazy osprey]

but the bundled js file doesn't. doesn't that mean it'll error if you use this declaration file?

(I have almost no experience making libraries for others to use)

[placid folio]

The output sort of does, if you squint at it. That's the IIFE equivalent of exporting two things, I guess. (Though I'd expect the IIFE to be called with some sort of global not just an empty object) Okay misread what this was doing

Declaration files generally don't change based on the output format that you're using.

Mostly I'd suggest outputting something like ESM or CJS which more directly matches how the TS code, if you can. If you need to use the IIFE format, you may need to make your own .d.ts file that declares the global variable.

[hazy osprey]

well this is used in non-module JS code

[placid folio]

Then yeah, you may want to add a .d.ts file to declare the global variable.

[hazy osprey]

gotcha. In other words, don't generate a .d.ts file. This feels strange to me. Is my case unusual?

[placid folio]

Writing non-module JS code nowadays is somewhat unusual, yeah.

[hazy osprey]

ah ok, that makes me feel better

[wanton forge]

yeah, exports in your input file + iife doesn't sound like they go together
ESM exports are for ES modules, not iife

[placid folio]

AFAIK TS has largely assumed everyone uses modules and left the wiring of non-module APIs up to either the package or the consumer.

[hazy osprey]

yeah, exports in your input file + iife doesn't sound like they go together
What would go together given I use an iife?

[placid folio]

I don't think generating the .d.ts file is necessarily wrong, but you'd at least maybe want another .d.ts file that's something like:

// index.global.d.ts
declare global {
   const DialogElementMacro: import("index.ts");
}

And then you may have to do something to get that included as part of your main types or else let consuming packages explicitly reference it.

[hazy osprey]

whoa, I've never seen an import in the middle of a file before

[placid folio]

Oops, that probably should be typeof import("index.ts") you can do type-only imports in type signatures