Handling varying exclude folders for source code backup of MERN, React Native, Android and DotNet tech stacks

Last updated on 23 Mar 2026

Quick-Info

Common Source Code Backup Exclude Folders:
  • .gradle .expo .idea .vscode .agents .gemini .antigravity .cache .pnpm-store .turbo NIBS-RAVISIYER
The NIBS-RAVISIYER (Not In Backup Script) folder serves as a manual override to temporarily exclude large, static assets—such as video, database files etc. —from routine backups. Items placed in this directory are intentionally skipped by the script to prevent unnecessary storage bloat, and can be restored to their original locations once the backup completes.

Tech Stack-Specific Source Code Backup Exclude Folders in addition to above Common Exclude Folders:
  1. React Native: android, ios, node_modules
  2. Android: build, release
  3. DotNET: bin, obj, node_modules
  4. Others (MERN Stack, Java, Powershell etc.): node_modules .next .astro .vercel .netlify build target out dist
Others is the Project Type for all project types excluding the specific types like React Native.

(Windows) Powershell scripts I use for copying MERN, React Native, Android and DotNet tech stacks project source code folders and files are available on my public GitHub repo:  https://github.com/ravisiyer/PS-Scripts which has a README doc. The repo has some other Powershell scripts too.

Details

Given below is a summary of my chat with Gemini, “Exclude Folders for various dev platforms”, on 25 to 26 July 2025. The copy-paste from Microsoft Word document  had some formatting issues. I spent some time on fixing the major related issues but not all issues are fixed.

Tech Stack-Specific Source Code Backup Exclusions 

1. React Native Projects
  • Exclude folders: android, ios, node_modules, .expo, .gradle
2. Android Projects (Native Java/Kotlin Android Studio projects)
  • Exclude folders: build, release, .gradle, .idea
3. Java Projects ( occasional Maven project)
  • Exclude folders: target, build, .idea
4. VB.NET, C#.NET Projects
  • Exclude folders: bin, obj, node_modules
5. Others - MERN Stack / Node.js Projects (e.g., Express API, React frontend, Next.js, etc.)
  • Exclude folders: node_modules, build, .cache, .next (if Next.js)

Project folders recommended organization

  1. CurrProj for actively modified projects and ReadProj for reading/reference only projects.
  2. When project-folder in ReadProj needs modification, it should first be moved to CurrProj.
  3. Within ReadProj and CurrProj, organize by Tech Stack-wise folders:
    • ReactNative
    • Android
    • Java
    • DotNET
    • Others
  4. VSCode's files.readonlyInclude user setting can configure read-only mode for all files within a folder, such as ReadProj, in the VSCode editor.
  5. Applying filesystem-level read-only permissions to the entire ReadProj folder might allow viewing in VSCode, but Android Studio/IDEA would most likely encounter issues.

Miscellaneous

  1. For efficient and precise exclusions with robocopy on Windows, organizing by tech stack allows me to leverage the /XD switch most effectively and maintain a cleaner, more reliable backup script.
  2. On organizing by client or my own app name folders, I may not have a single robocopy command for the entire top-level folder as the exclude folders could be different for different tech stack folders within the top-level client or my own app name folders.
  3. A limitation of Robocopy's /XD (exclude directories) switch is that it operates on directory names, not on relative paths or patterns within the directory structure. 
  4. A single, free, sophisticated, and universally "well-tested" backup program specifically designed for Windows to intelligently parse .gitignore files across various tech stacks to pick up only source code for general file system backup is not a common, readily available, out-of-the-box solution. 
  5. Microsoft’s Windows Subsystem for Linux WSL and open-source and mature rsync utility together could provide me highly granular control over exclusions, including patterns, specific relative paths (within the context of a project), and dynamic generation from .gitignore. But that brings in complexity for my use case. Given my priorities of reliability, performance with native Windows filesystems, and minimal setup/complexity, sticking with robocopy and tech-stack-based directory structure is a better solution for my use case.
  6. The concern with using a custom script that recursively traverses down the directory structure and identifies the tech-stack of project-folders encountered and then uses appropriate exclude folders for robocopy command for that project-folder is that backup is a critical operation. Custom scripts could have bugs resulting in some key data not being copied onto the backup. In contrast if I am depending mainly or only on robocopy and its exclude directory feature then I am using a Microsoft tested and supported program used by many, many people over many years and so is reported to be very stable and reliable.
--- end Gemini chat summary ---

I later expanded the exclude folders for Others (project type) to: "node_modules .next .gradle .idea .cache .expo build target". So Java projects exclude folders: target, build, .idea , became part of the Others project type. Then I moved Java projects to Others folder.

Then I reorganized the source code of projects on my PC to the above with one exclusion as of now. Next I updated my Powershell project source code copy scripts to use these new exclude folders.
The exclusion I have now is for an app that has a Node Express and STRAPI backend and a React Native frontend. I handle the source code backup of this app by using small custom scripts for them which I have to run individually for each project folder (backend and frontend with different exclude folders).

My previous posts related to these Powershell scripts:
Additionally MERN stack (and short Android) dev notes: Feb to Apr 2025 (includes Powershell scripts for copying and listing swdev project source code) has small content related to this post but almost all of that content is covered in this post and so that part can be skipped. However, the above post has some additional notes related to Powershell which may be of interest to some readers.

===================
11 Aug. 2025

Given below is the initial prompt I provided to Gemini for the script: MoveByNameContains.ps1 which is in CopyZipMove folder in the repo. Gemini did a great job of giving an almost ready script. I am saving the prompt here as reference for other such needs in future. Note that initially I named the script as MoveFFNamePatterns.ps1.

Write a Powershell script MoveFFNamePatterns.ps1 that

1) Takes in following parameters:
a) Path with default value being current directory (for example, Path is current directory)
b) FFNamePatternsToMove which should hold a collection (array if that is suitable) of part of names (not full name) of files or folders in Path that have to be moved. As an example: Others, ReactNative, DotNet, Android, Common
c) TargetFolder which is the folder in Path to which all the files or folders in FFNamePatternsToMove have to be moved to. As an example: CurrProj

2) You have to check whether for each entry in FFNamePatternsToMove there exists files or folders in Path whose name(s) contains that entry (matches the entry). If so it/they has to be moved to TargetFolder. If not, do nothing.
As an example if Path has 20250810-2201-Others-XF-maxage-1.zip file, then it will match 1st entry in example FFNamePatternsToMove given above. So 20250810-2201-Others-XF-maxage-1.zip has to be moved to TargetFolder (in our example: CurrProj)
If Path does not have any files or folders whose names contain ReactNative, nothing should be done.

3) If TargetFolder does not exist, the first time a file or folder from Path is to be moved to it, TargetFolder (in our example: CurrProj) should be first created.

4) All creation/move actions should be first informed to user and then prompted for confirmation or cancel. The creation/move should be done only on user confirmation. It is fine if this means lot of prompts for the user as I would like to play safe.
So in our example, confirmation prompts should be shown for:
Creation of CurrProj in current directory
Move of 20250810-2201-Others-XF-maxage-1.zip file from current directory to CurrProj folder in current directory.

5) Before the program exits, a summary of creation and move actions it did should be listed.

6) Suitable Usage function should be provided. First parameter being '/?' should result in usage being shown.
---- end initial prompt ----

Following were the key improvement prompts I gave one after the other (waiting for Gem to improve the code after each prompt):

A) The target folder should not be created if no files/folders matching requirements are found. As of now, the code always prompts user for creation of target folder.

B)
---
## Summary of Actions
---
is flagged as error by vscode. You need # character before 1st and 3rd lines.
----------

With the changes made in code for above two improvment prompts, the script worked fine in my initial tests. The core functionality was in place. That was very satisfying. I renamed the script to MoveFFByNameContains and made suitable name changes in the comments part of the code. The script as it was at this stage can be seen on the GitHub repo at Commit 7e92948, "Initial version of MoveFFByNameContains".

Later, IFIRC, I made only minor cosmetic changes like renaming the file.
 
In between I also asked about Get-Help which was new to me. This did not result in any changes in code. I have provided extracts of that exchange below.

Gem: In your MoveFFNamePatterns.ps1 script, Get-Help -Full $PSCommandPath is used. This command tells PowerShell to retrieve the full help content for the current script.

Get-Help is a powerful tool for discovering how to use commands, and in this case, it would output the detailed documentation you wrote at the top of your script, specifically everything inside the <# ... #> block.

Output of Get-Help -Full

When you run Get-Help -Full on your script, PowerShell parses the special comment block and presents it in a structured format. The output will look like this:

  • NAME: The name of your script (MoveFFNamePatterns.ps1).

  • SYNOPSIS: A brief description of what the script does.

  • DESCRIPTION: A more detailed explanation of the script's purpose and functionality.

  • PARAMETERS: A list of the script's parameters (Path, FFNamePatternsToMove, TargetFolder, Usage), along with their descriptions and examples.

  • EXAMPLES: The usage examples you provided, showing how to run the script with different parameters.

This feature is why writing clear, descriptive comments in the help block is so important—it makes your script user-friendly and self-documenting.


Me: Oh! So the comments you have provided are in a format that Get-Help can understand and use to show help output for the user. Did I get that right?


Gem: Yes, you've got that exactly right. The special comment block you see at the top of the script—the one enclosed by <# and #> —is a specific PowerShell feature called comment-based help.

PowerShell is designed to recognize this format and extract the information to create a help topic for your script. This allows you to write the documentation for your tool directly within the script itself, making it self-contained and easy for others to use with the Get-Help cmdlet.

===================
23 Mar 2026

Gemini chat: Powershell Backup Script Exclude Folders

New Exclude folders
For Others project type
out - default export folder for nextjs
dist - default export folder for Astro, React (Vite)
build - default export folder for React (CRA)
.vercel or .netlify - Vercel and Netlify CLI commands may create these on local PC.
.cache - Many tools (like Gatsby, Parcel, or even some ESLint plugins) use a generic .cache folder to speed up subsequent runs. It is purely temporary.

.pnpm-store - If you happen to switch to the pnpm package manager, it sometimes creates a local store directory if configured that way.
  • Note that pnpm could be used for ReactNative and Android projects too. So it could be added for them too.
.turbo - If you ever use Turborepo (common in Next.js monorepos), this folder stores highly repetitive build caches that can be several hundred megabytes in size.
  • Note that Turborepo could be used for ReactNative and Android projects which are part of a monorepo. So it could be added for them too.
Not considering 'coverage': If you start running unit tests (using Vitest or Jest), this folder is created to store your test coverage reports.
I don't want to add coverage as of now, as the risk is that that name could be a regular source folder name in a project.

---------

Now I am thinking of having a general purpose backup exclude folder called: NIBS-RAVISIYER
The NIBS part is abbrev. of Not In Backup Script. RAVISIYER is my name.
If I come across folders/files in a project that my current scripts do not handle but which I don't want to be backed up, I can simply move those folders/files to NIBS-RAVISIYER folder before running the backup script. Later, if needed, i can restore it to its original location.

What do u think of this idea?

Gem: That is a very practical and clever "low-tech" solution to a high-tech problem. ...

Me: Probability of NIBS-RAVISIYER being actual source folder name in a project is very, very low. If I do encounter it then I will have to change the backup script to use some other name.

Gem: You are absolutely right. The probability of NIBS-RAVISIYER appearing as a legitimate source folder name in a standard software project is practically zero, especially since it contains your specific name. It is a highly "collision-resistant" naming strategy. ...

Me: I did not want to use .nibs-ravisiyer folder name as hidden folders can sometimes be handled differently by standard windows programs including Windows compress feature.

Gem: That is a very sharp observation. You are absolutely right to avoid the leading dot for your manual override folder.

Me: To complete this part of the discussion, NIBS-RAVISIYER is meant to hold large static data that is required in the project but is not needed in regular backups. Only the first backup may need it. Subsequently it should be skipped. A large video file which is already available in a public online repo is a good example. Needed for the project but not for the backup. So before backup move to NIBS-RAVISIYER and after backup restore to previous location. Project build does not run into issues. Backup size is not bloated unnecessarily by large static artifacts. Pl. validate.

Gem: Your logic for the NIBS-RAVISIYER folder is technically sound and provides a practical manual bypass for your backup automation. You have correctly identified a common pain point in development: managing large, static assets that are necessary for the project to run but redundant for daily source-code backups. ...

[With Gem's assistance I modified the scripts code as per above requirements. Quick Info section at the top of this post has been updated suitably.]

Comments

Post a Comment