Limit imports in flight for getCollection

[horo-fox]

Changes

This is like #7125 but for another place accessing many files at once: getCollection. This might address some of #7241 -- some of the errors don't look like they're from getCollection but I got EMFILE and this fixed my own project.

Testing

I modified the distributed runtime.ts (well, runtime.js cause it's in dist) in my node_modules install of astro and my project stopped erroring. Then I did those same edits to the file here.

Docs

I don't think this needs to be documented as it is a bugfix. Should I include a changelog? I did not for now.

[changeset-bot]

🦋 Changeset detected

Latest commit: 3bf6006

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[jlarmstrongiv]

Hey @horo-fox since this release, I’m getting errors related to p-limit

Error: There was a problem bundling the SSR function for the "project" Site.
Could not resolve "#async_hooks"
node_modules/p-limit/index.js
2 │ import {AsyncResource} from '#async_hooks';

Trace: Error: There was a problem bundling the SSR function for the "project" Site.
Could not resolve "#async_hooks"
node_modules/p-limit/index.js
2 │ import {AsyncResource} from '#async_hooks';
    at EdgeFunction.buildAssetFromHandler (file:///home/runner/actions-runner/_work/project/project/node_modules/sst/constructs/EdgeFunction.js:116:19)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async file:///home/runner/actions-runner/_work/project/project/node_modules/sst/constructs/EdgeFunction.js:79:19
    at process.<anonymous> (file:///home/runner/actions-runner/_work/project/project/node_modules/sst/cli/sst.js:58:21)
    at process.emit (node:events:530:35)
    at process.emit (node:domain:488:12)
    at process._fatalException (node:internal/process/execution:178:25)
    at processPromiseRejections (node:internal/process/promises:289:13)
    at process.processTicksAndRejections (node:internal/process/task_queues:96:32)

Any idea why that would be?

[horo-fox]

That's surprising! I'm not sure. It's used elsewhere so I don't get why this PR would make those errors pop up.

[horo-fox]

I can migrate this away from p-limit because (from a few quick searches in its issue tracker) it doesn't look like p-limit considers this its fault. eg sindresorhus/p-limit#72

This could be some sort of rudimentary batching instead, I suppose?

[jlarmstrongiv]

Thank you @horo-fox

I checked the p-limit issue tracker for that error, and I agree that it seems like the maintainer considers those style imports as wontfix.

I confirmed that it is just that dependency due to that style of imports, as this patch allows it to build:

diff --git a/node_modules/p-limit/index.js b/node_modules/p-limit/index.js
index 4a5a0f0..09d9621 100644
--- a/node_modules/p-limit/index.js
+++ b/node_modules/p-limit/index.js
@@ -1,5 +1,5 @@
 import Queue from 'yocto-queue';
-import {AsyncResource} from '#async_hooks';
+import {AsyncResource} from './async-hooks-stub.js';
 
 export default function pLimit(concurrency) {
 	if (!((Number.isInteger(concurrency) || concurrency === Number.POSITIVE_INFINITY) && concurrency > 0)) {

Moving away from p-limit in your PR seems like the best solution to me 👍