How should we handle OneDrive getting stuck on Node.js project folders?

Keep the project’s source files and configuration, but not the generated dependency folder. In a typical Node.js project, node_modules can be recreated from the package manifest and lockfile, so syncing it adds a huge number of files without usually preserving unique work. That only helps if the project includes those files or has a lockfile that lets dependencies be reproduced reliably.

For users who should not need to run package commands, make the supported workflow handle setup and recovery for them. A managed tool or documented support process can restore the project from its source and lockfile, rather than asking users to understand the build steps.

This sounds like a storage-policy mismatch. OneDrive is meant for user files, not as a general-purpose source-control or build-artifact store. Put project source in an organization-managed version-control service, and decide separately where generated files belong. That also gives you history and a way to recover work that a synced folder alone may not provide.

There is some nuance around SharePoint-based tools: a service built on the same underlying platform is not automatically unsuitable for code, but ordinary file sync is a different workflow from version control. Pick a supported repository service and make access, backups, and recovery part of the setup.

Before changing the storage rule, check what the AI tool actually creates and what users need to keep. Excluding node_modules is a reasonable first test, but generated files can include user-authored data or outputs that are not easy to reproduce. Confirm the project can be rebuilt from the remaining files before treating those folders as disposable.

For the longer term, give users a managed path that saves source and required inputs to an approved repository or workspace, with a simple restore process. Also review whether users are allowed to install arbitrary packages or run project scripts. Dependencies can carry security risk, so storage performance is only part of the problem.

For an immediate workaround, move active projects outside the OneDrive sync root and avoid syncing node_modules. Don’t just zip the entire project and call that the long-term fix. It may reduce the number of sync operations, but it leaves you without useful source history and can still preserve unnecessary generated content.

Then pilot a repository-based workflow with a few users. If they are not developers, the interface needs to be simple enough that saving and restoring work does not depend on them learning command-line tools.