@brc-dd do you think it is safe?

Yeah. It's quite standard way to avoid caching. For most cases, it won't affect anything (as generally every tool calls postcss-load-config only once or twice). But for test runners that don't properly isolate stuff, this is needed if you're writing/reading config from same paths. Jiti supports JITI_CACHE env variable to customize this behavior, but for native imports, I guess it's fine to bypass caching.

OP can probably explain what exactly their use-case is.

There is a memory leak associated with this though (refer comments in nodejs/node#49442). But those are hard to avoid, and like I said since tools don't load postcss config too many times, it should fine.

There is a memory leak associated with this though (refer comments in nodejs/node#49442). But those are hard to avoid, and like I said since tools don't load postcss config too many times, it should fine.

I'd like to understand this better (as I have a usecase where the postcss.config.js would reload quite often)

I'd like to understand this better

From what I understand, node's module cache has circular references and gc cannot exactly know if a particular module is no longer used.

With this PR, each call to postcss-load-config will make node treat the config as a separate module, and the module cache will grow over time. From my tests, the memory leak seems to be there in deno and bun as well.

Without this PR, each call to postcss-load-config will return the same config even if the config has changed.

With this PR, each call to postcss-load-config will make node treat the config as a separate module, and the module cache will grow over time. This behavior is same on deno.

I see - Is there no garbage collection active on unused modules in the module cache?

Is there no garbage collection active on unused modules in the module cache?

Yeah, node/deno/bun currently don't remove anything from the module cache, nor provide any way to do that.

I need some proof that it will not make everything worse.

For instance, that some big projects use the same approach.

Astro has this - https://github.com/withastro/astro/blob/b956149b2805fdd977d20e267f05c6c4872e2704/packages/astro/src/core/config/vite-load.ts#L45

Nx has - https://github.com/nrwl/nx/blob/09abd39ecc1e11ef94b404d4512fca3526d20d31/packages/remix/src/utils/remix-config.ts#L52 / https://github.com/nrwl/nx/blob/09abd39ecc1e11ef94b404d4512fca3526d20d31/packages/remix/src/plugins/plugin.ts#L189

Sindre's repo has this way mentioned - https://github.com/sindresorhus/import-fresh?tab=readme-ov-file#esm

Directus - https://github.com/directus/directus/blob/e888ba8112384b950723b128d7e4642ad8bc8d7b/api/src/utils/import-file-url.ts#L11

Thanks. Released in 5.0.3.

Thanks. Released in 5.0.3.

❤️