🐛 TypeError from unhandled `undefined` in eleventy plugin

[aarongoldenthal]

Prerequisites

• I'm using the latest version
• I've read the relevant documentation
• I've searched for existing issues
• I've checked the list of known issues
• I've read the issue reproduction guide

Reproduction url

https://gitlab.com/aarongoldenthal/aarongoldenthal (sorry, not a minimal reproduction, but the issue and fix is below)

Reproduction access

• I've made sure the reproduction is publicly accessible

Description of the issue

In some cases, running knip on an eleventy project fails with the following error (this is the Alpine Linux output, but occurs on Win 11 as well)

$ knip
file:///usr/local/lib/node_modules/knip/dist/plugins/eleventy/index.js:19
    const templateFormats = localConfig.templateFormats || defaultEleventyConfig.templateFormats;
                                        ^
TypeError: Cannot read properties of undefined (reading 'templateFormats')
    at Object.resolveConfig (file:///usr/local/lib/node_modules/knip/dist/plugins/eleventy/index.js:19:41)
    at async runPlugin (file:///usr/local/lib/node_modules/knip/dist/WorkspaceWorker.js:276:40)
    at async WorkspaceWorker.runPlugins (file:///usr/local/lib/node_modules/knip/dist/WorkspaceWorker.js:319:13)
    at async build (file:///usr/local/lib/node_modules/knip/dist/graph/build.js:94:35)
    at async main (file:///usr/local/lib/node_modules/knip/dist/index.js:[43](https://gitlab.com/aarongoldenthal/aarongoldenthal/-/jobs/10184307712#L43):88)
    at async run (file:///usr/local/lib/node_modules/knip/dist/cli.js:26:111)
    at async file:///usr/local/lib/node_modules/knip/dist/cli.js:111:1
Node.js v22.16.0

The issue is in line

knip/packages/knip/src/plugins/eleventy/index.ts

Line 31 in 8aa2f13

const templateFormats = localConfig.templateFormats || defaultEleventyConfig.templateFormats;

of the plugin. The error occurs when localConfig is undefined, and this line is the one that doesn't handle that.

The following change resolved the issue.

-  const templateFormats = localConfig.templateFormats || defaultEleventyConfig.templateFormats;
+  const templateFormats = localConfig?.templateFormats || defaultEleventyConfig.templateFormats;

[webpro]

As you got this far, maybe you'd like to contribute and send a pull request?

No worries if not! Just let me know.

[aarongoldenthal]

As you got this far, maybe you'd like to contribute and send a pull request?

No worries if not! Just let me know.

@webpro I'm happy to submit a PR, hopefully this weekend. I would like to dig in a little more and understand why the workarounds I tried did not work. I'm a recent convert from depcheck, so still working through the config and plugin docs. It's a great tool though, and has already caught a few things depcheck and I had missed.

[webpro]

Thank you for the kind words, let's make it even better ❤️ Here to help.

[aarongoldenthal]

@webpro I think I figured out why it isn't a problem for everyone, and it seems related to the implementation added in #454. The Eleventy config can follow one of a few options, as shown in the docs. The current implementation assumes the callback function that returns an object (the second option). My Eleventy config has the callback function (that returns nothing) with the named config export (the first option), which is what all the Eleventy examples use and I build from that. So, when I run knip this line returns undefined:

knip/packages/knip/src/plugins/eleventy/index.ts

Line 27 in 8aa2f13

if (typeof localConfig === 'function') localConfig = (await localConfig(dummyUserConfig)) as EleventyConfig;

It also means it's using the defaultEleventyConfig values instead of my actual values, so some things aren't properly resolved even when it runs with the original fix I proposed (which I still think needs to be made for completeness). I'm not sure if knip has a way (or if there's an example) of importing the default function from config as well as the named property. I'm also not sure it's an issue to assume a specific format for the config, but that's probably worth adding to the docs if that's the case.