LRU Cache is not a constructor issue in Microsoft Office addin

[Peterhague]

Hi I'm developing an Excel addin via the yeoman generator, which includes LRU Cache package as a dependency (not sure of which of the dependencies in pakcage.json). The code now throws an error (Typeerror: LRU Cache is not a constructor) on running npm start to run the app.

The code stopped working some time between evening GMT of Thursday and 9am GMT Friday - I can see that there was a new version of LRU Cache around that time so assume the issue is related to that.

Can you advise at all?

Many thanks

Peter

[isaacs]

What does npm ls lru-cache output?

What package manager are you using?

Something in your dep tree is getting a version that it doesn't know how to use. This is likely a package manager issue.

[fridaystreet]

seems like this is a pretty ongoing/reoccuring issue with this library, quite a few historical issues with the same thing. I realise it's package manager related, but I've never seen this with any other package. Is there any chance maybe there is something to do with this package that maybe could be a bit more compatible?

[KernelDeimos]

seems like this is a pretty ongoing/reoccuring issue with this library, quite a few historical issues with the same thing. I realise it's package manager related, but I've never seen this with any other package. Is there any chance maybe there is something to do with this package that maybe could be a bit more compatible?

It's 2025 and I'm dealing with the same issue and the nuance behind this is absolutely wild. I'm still missing information, but this is what I know so far:

The maintainer of this package changed how the class is exported. Instead of a default export, it exports the class by name. This happened in a commit before 9.0.0 was released. The maintainer didn't do anything wrong here; they bumped the major version up which is exactly what we should expect. So, why is this error happening everywhere?

This module has a lot of dependents. If you're using lru-cache, there's a good change you have other dependencies also using other versions or lru-cache. Some before this change, some after.

In our issue on Puter - and I don't know why this happens only in the GitHub action - npm ci and npm install do not install [email protected] despite that this is in our package.json and package-lock.json files. It's able to get it when running locally or when building the Dockerfile locally, but not when the Dockerfile is built within our GitHub action that registers our release image to ghcr.io. The result of this is that node falls back to [email protected] when our code tries to import the module, which isn't compatible and produces this error message.

As a bit of an aside, it's terrifying that this fallback behavior occurs. Imagine this were a security-sensitive package and it didn't cause a runtime error, but fell back to an older version of the module silently. npm audit wouldn't catch this, everything would look fine, but a release image could be compromised without anybody having the slightest indication.