Add archiver patches back to fix following symlinks on export

[wojtekn]

Related issues

• Follow-up to Upgrade archiver to v7 to fix glob and inflight deprecation warnings #3050

How AI was used in this PR

I used AI to regenerate patches and revert unnecessary changes from the previous PR.

Proposed Changes

I propose adding patches that add follow-symlinks option to archiver.

Testing Instructions

1. Create a Studio site
2. Symlink directory e.g. plugin
3. Cnofirm plugin loads on site
4. Export site
5. Confirm directory is included in package, and it's not a symlink

Pre-merge Checklist

• Have you checked for TypeScript, React or other console errors?

[wpmobilebot]

📊 Performance Test Results

Comparing 1428970 vs trunk

app-size

Metric	trunk	1428970	Diff	Change
App Size (Mac)	1286.16 MB	1286.16 MB	0.00 MB	⚪ 0.0%

site-editor

Metric	trunk	1428970	Diff	Change
load	1611 ms	1824 ms	+213 ms	🔴 13.2%

site-startup

Metric	trunk	1428970	Diff	Change
siteCreation	8116 ms	9120 ms	+1004 ms	🔴 12.4%
siteStartup	4928 ms	4315 ms	613 ms	🟢 -12.4%

---

Results are median values from multiple test runs.

Legend: 🟢 Improvement (faster) | 🔴 Regression (slower) | ⚪ No change (<50ms diff)

[epeicher]

Thanks @wojtekn for adding those! I have tested running npm install and running npm start and I don't see any errors. I have tested exporting a site with symlinks and I see the symlinked plugin folder in the new site. I have added a commit that removes the types @types+archiver+7.0.0.patch because that patch was not necessary and it was also breaking the CI. Once the CI passes this could be merged. LGTM!

Symlink site	Imported previously exported site

[fredrikekelund]

Let's remove the as archiver.ArchiverOptions type assertions from #3050. That can easily hide errors in the future

[fredrikekelund]

Ah, I see now that we'd also need to patch @types/archiver for that to work… I think we should either do that or add a line like this:

// @ts-expect-error The `followSymlinks` option comes from a patch

The latter option is probably easier and clearer, actually.

[epeicher]

Let's remove the as archiver.ArchiverOptions type assertions from #3050. That can easily hide errors in the future

@fredrikekelund adding @types/archiver breaks the build as they are added to the devDependencies and it's dropped when patch-package runs (some details here)

I'm curious, why do you think it can hide errors in the future?

add a line like this:

// @ts-expect-error The `followSymlinks` option comes from a patch
The latter option is probably easier and clearer, actually.

That seems a good approach.

[fredrikekelund]

I'm curious, why do you think it can hide errors in the future?

Because it effectively disables type checking. Typescript won't complain about misnamed, missing, or unrecognized props.

I think the @ts-expect-error makes it clear that we're doing something custom, which is great.

[wojtekn]

@epeicher @fredrikekelund I remove those casts and added explicit @ts-expect-error where it was needed.

[epeicher]

Because it effectively disables type checking. Typescript won't complain about misnamed, missing, or unrecognized props.

That makes sense, thanks for the explanation @fredrikekelund. That's a strong reason to always try to avoid type casting 👍