search

philcockfield / file-system-cache

A super-fast, promise based cache that reads and writes to the file-system.
MIT License
52 stars 14 forks source link

No "exports" main defined when upgrading to v3.0.0 #52

Open conorfuller opened 1 month ago

conorfuller commented 1 month ago

Hello!

First and foremost, thank you for the awesome library - we've been using it for a few weeks now and are very impressed with the results. We attempted to upgrade to the latest 3.0.0 version today however, and we're now getting:

Error [ERR_PACKAGE_PATH_NOT_EXPORTED]: No "exports" main defined in /Users/conorfu/....../node_modules/file-system-cache/package.json [Storefront Client] at new NodeError (node:internal/errors:405:5) [Storefront Client] at exportsNotFound (node:internal/modules/esm/resolve:259:10) [Storefront Client] at packageExportsResolve (node:internal/modules/esm/resolve:533:13)

This is a Node 20/Next 14 based application and we are using a commonjs environment and am unable to switch easily to use ESM. Is it possible to add default exports to the package.json for increased module support? As has been done here for next/auth https://github.com/nextauthjs/next-auth/pull/11224/commits/b1a81024071e688cb4168c81047ac97febb91691

conorfuller commented 1 month ago

Our very basic usage in the code if it helps:

`import Cache from 'file-system-cache';

const cache = Cache({ basePath: './.images', ttl: configuration.IMAGES_CACHE_TTL });`

gitSambhal commented 1 month ago

@conorfuller use version 2.4.7.

npm i file-system-cache@^2.4.7

conorfuller commented 1 month ago

Thanks @gitSambhal, unfortunately we have a strict security policy that all versions must be on the latest available so rolling back isn't an option for us.

gitSambhal commented 1 month ago

@conorfuller not sure about your usecase but I am using https://github.com/maxpert/node-cache-manager-sqlite, you can try that.

philcockfield commented 1 month ago

Hi there @conorfuller - thanks for the issue report, and @gitSambhal

Yes, locking to 2.4.4 version is the solution here UNLESS this is all gonna be such a PITA for the upstream projects that we need to rethink going to ESM. But this is not the future, and so I am reluctant.

Here is some context (strong personal opinions lightly held 😄):

This change came in due to a PR (submitted by one of the core Storybook team) updating the project to only support ESM bundling.

I published this change to a major v3 (as it is a breaking change) and on the whole feel we as an entire JS community should be moving to proper ESM support and ditching CJS. Node itself has been frustratingly slow in forcing this issue, and to it's detriment, as the world starts moving away from node itself because of things like this.

Major libraries started doing this a few years ago, the standard itself being ~10 years old. Back then it was a total PITA for me for me when major libraries started doing this, so I do feel the pain.

This is a Node 20/Next 14 based application and we are using a commonjs environment and am unable to switch easily to use ESM. Is it possible to add default exports to the package.json for increased module support? As has been done here for next/auth https://github.com/nextauthjs/next-auth/commit/b1a81024071e688cb4168c81047ac97febb91691

That's super helpful @conorfuller - lemme figure that out, and see if I can get that into a release for you.