[SPFx] `copy-assets` bundle step taking very long time - what is it doing?

[JakeStanger]

What type of issue is this?

Question

What SharePoint development model, framework, SDK or API is this about?

💥 SharePoint Framework

Target SharePoint environment

SharePoint Online

What browser(s) / client(s) have you tested

• 💥 Internet Explorer
• 💥 Microsoft Edge
• 💥 Google Chrome
• 💥 FireFox
• 💥 Safari
• mobile (iOS/iPadOS)
• mobile (Android)
• not applicable
• other (enter in the "Additional environment details" area below)

Additional environment details

• SPFx version: 1.11.1
• Node.js version: 10.19.0
• Ryzen 7 3800, 32GB RAM, M.2 drive
• Running Linux, so no concern of antivirus etc

Issue description

When running gulp bundle --ship, the copy-assets step takes a very long time for some projects, hugely disproportionate to the rest of the build time.

I've included the relevant parts of the build log below, and you can see that while tsc took just over 7 seconds, and webpack took 27, copy-assets took over 3 minutes.

I'm running pretty beefy hardware so I can't see that that's the issue. I've also tried upping Node's memory with NODE_OPTIONS=--max_old_space_size=8192 to no avail.

I'd like to better understand what the step is doing internally to try and work out what's causing the step to take so long.

[11:48:16] Starting gulp
[11:48:16] Starting 'bundle'...
[11:48:16] Starting subtask 'configure-sp-build-rig'...
[11:48:16] Finished subtask 'configure-sp-build-rig' after 3.51 ms
[11:48:16] Starting subtask 'pre-copy'...
[11:48:16] Finished subtask 'pre-copy' after 2.2 ms
[11:48:16] Starting subtask 'stylelint'...
[11:48:17] Finished subtask 'stylelint' after 868 ms
[11:48:17] Starting subtask 'copy-static-assets'...
[11:48:17] Starting subtask 'sass'...
[11:48:18] Finished subtask 'copy-static-assets' after 774 ms
[11:48:18] Finished subtask 'sass' after 850 ms
[11:48:18] Starting subtask 'tsc'...
[11:48:18] [tsc] typescript version: 3.9.7
[11:48:25] Finished subtask 'tsc' after 7.3 s
[11:48:25] Starting subtask 'eslint'...
[11:48:35] Finished subtask 'eslint' after 9.26 s
[11:48:35] Starting subtask 'post-copy'...
[11:48:35] Finished subtask 'post-copy' after 52 μs
[11:48:35] Starting subtask 'collectLocalizedResources'...
[11:48:35] Finished subtask 'collectLocalizedResources' after 2.91 ms
[11:48:35] Starting subtask 'configure-webpack'...
[11:48:35] Finished subtask 'configure-webpack' after 137 ms
[11:48:35] Starting subtask 'webpack'...
[11:49:02] Finished subtask 'webpack' after 27 s
[11:49:02] Starting subtask 'configure-webpack-external-bundling'...
[11:49:02] Finished subtask 'configure-webpack-external-bundling' after 312 μs
[11:49:02] Starting subtask 'copy-assets'...
[11:52:24] Finished subtask 'copy-assets' after 3.35 min
[11:52:24] Starting subtask 'write-manifests'...
[11:52:24] Finished subtask 'write-manifests' after 426 ms
[11:52:24] Finished 'bundle' after 4.13 min

Thank you for reporting this issue. We will be triaging your incoming issue as soon as possible.

[github-actions]

Thank you for taking the time to file an issue. We periodically archive older or inactive issues as part of our issue management process, which automatically closes them once they are archived.

If you’d like to understand more about why and how we handle archived (closed) issues, please see Our approach to closed issues.

We appreciate your contribution and if this is still an active issue with the latest SPFx versions, please do resubmit the details. We needed to perform a cleanup, so that we can start with a clean table with a new process. We apologize for the inconvenience this might cause.