How the `.difyignore` File Is Processed Compared to `.gitignore` in Dify Plugin Repackaging

The Dify plugin repackaging script prioritizes .difyignore over .gitignore, falling back to the latter only when the former is missing, then strips wheels/ entries before packaging.

When building offline Dify plugin packages using the junjiem/dify-plugin-repackaging tool, the plugin_repackaging.sh script must determine which files to exclude from the final archive. The script implements a hierarchical ignore-file strategy that allows project-specific Dify packaging rules to coexist with standard Git ignore patterns.

Priority and Fallback Logic

The repackaging engine resolves the ignore file through a strict priority chain defined in plugin_repackaging.sh at line 126.

Primary choice: The script first attempts to use .difyignore, a dedicated ignore file for Dify packaging workflows. This allows developers to define exclusion rules specific to the plugin build process without polluting their version control configuration.

Graceful fallback: If .difyignore does not exist in the project root, the script automatically resets IGNORE_PATH to .gitignore (lines 127-128). This ensures the repackaging operation can still proceed using existing ignore rules, maintaining compatibility with repositories that have not yet adopted the Dify-specific file.

Processing Pipeline in plugin_repackaging.sh

Once the ignore file is selected, the script executes a four-step validation and transformation pipeline:

1. File Existence Verification

Before processing, the script confirms the resolved ignore file actually exists (line 130). This prevents errors when neither .difyignore nor .gitignore is present.

2. wheels/ Entry Stripping

The script removes any line beginning with wheels/ from the ignore file (lines 131-136). This is critical because the repackaging process must include wheel files in the final package, even if they are normally excluded from version control.

The implementation handles cross-platform sed syntax differences:

# Linux/GNU sed

sed -i '/^wheels\//d' "$IGNORE_PATH"

# macOS/BSD sed (creates .bak backup)

sed -i ".bak" '/^wheels\//d' "$IGNORE_PATH"
rm -f "$IGNORE_PATH.bak"

Practical Examples

Example 1: Using a Custom .difyignore

Create a .difyignore file in your plugin repository:

# .difyignore

wheels/
config/local.yaml
tests/

When you run:

./plugin_repackaging.sh local ./my_plugin.difypkg

The script selects .difyignore, strips the wheels/ line (allowing wheels to be packaged), and excludes config/local.yaml and the tests/ directory from the final archive.

Example 2: Falling Back to .gitignore

If your repository only contains a .gitignore:

# .gitignore

*.log
wheels/
__pycache__/

The script automatically uses .gitignore as the ignore source. It removes the wheels/ entry (ensuring wheels are included in the package) while maintaining the exclusion of *.log files and __pycache__/ directories.

Summary

• .difyignore takes precedence over .gitignore when both exist, allowing Dify-specific packaging rules.
• Automatic fallback to .gitignore ensures backward compatibility for repositories without the Dify-specific file.
• ** wheels/ entries are stripped** from whichever ignore file is used, ensuring wheel dependencies are included in the final package despite version control exclusions.
• Cross-platform compatibility is maintained through platform-specific sed syntax handling in plugin_repackaging.sh.

Frequently Asked Questions

What happens if neither .difyignore nor .gitignore exists?

The script verifies file existence at line 130 of plugin_repackaging.sh. If the resolved ignore file does not exist, the script will fail to proceed with the exclusion logic, effectively packaging all files in the directory without ignore-based filtering.

Why does the script remove wheels/ entries from the ignore file?

The repackaging process must include wheel files in the final .difypkg archive to ensure the plugin works offline. However, wheels are typically excluded from Git repositories via .gitignore. The script strips these entries to override the exclusion and bundle the necessary dependencies.

Can I use both .difyignore and .gitignore simultaneously?

No, the script uses an either/or approach. It checks for .difyignore first and uses it exclusively if found. Only when .difyignore is absent does it fall back to .gitignore. You cannot merge rules from both files in a single repackaging operation.

Is the .difyignore syntax identical to .gitignore?

Yes, the script treats both files as standard ignore lists using pattern matching compatible with Git's ignore syntax. The only difference in processing is the removal of wheels/ lines and the priority given to .difyignore over .gitignore.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}