fix!: import `defineConfig` from `kirbyup/config` (#19)

[johannschopplich]

Fix #19.

@jonaskuske What do you think? Seems like the most straight forward solution.

[jonaskuske]

Would've said it looks good, but now that I've tested it, it doesn't appear to work :(

TS / IntelliSense doesn't pick up on the export, there's no auto-complete and auto-import for defineConfig and if you import it manually it still doesn't offer type completion. 🤔

[johannschopplich]

Node.js v12+ extends package entry points features like subpath exports or conditional exports, but TypeScript supports them only with the NodeNext module resolution:

{
  "compilerOptions": {
    "moduleResolution": "NodeNext"
  }
}

Reference: https://github.com/microsoft/TypeScript/issues/33079

Because many developers, including myself, are using "moduleResolution": "Node" solely, we add a workaround utilizing typesVersions.

[jonaskuske]

Found the culprit!

The downstream project needs to add a jsconfig.json / tsconfig.json with

{
  "compilerOptions": {
    "moduleResolution": "Node16"
  }
}

so TypeScript/IntelliSense correctly resolves package.json#exports.

With that, suggestions work if you try to import the function and the typings work too.

Auto-import still doesn't work, so you can't just type defineC, hit Tab and VSCode completes the function name and adds the import to the top automatically, but that's just a minor issue.

Edit: heh, a couple minutes too late :D

[jonaskuske]

Update: the workaround is working!

Still not for auto-imports, but that might just be a TS/IntelliSense bug or limitation?

[johannschopplich]

Limitation of the types version workaround. Still, everything we can do upstream inside the package.

[jonaskuske]

Limitation of the types version workaround

Are you sure? I see the same behavior with "moduleResolution": "Node16" and without the typesVersion workaround, so maybe it's a broader bug with type indexing/acquisition in ESM modules?

[johannschopplich]

Good question, I don't know. 👀