gruntjs / gruntjs/grunt

Need configurable 'Safe Delete' functionality for files outside current Gruntfile.js directory

Open
#959 0 comments 0 reactions 0 assignees View on GitHub
Type: Enhancement
Dominant language
JavaScript
Stars
12.2k
Forks
1.5k
PR merge metrics
No merged PRs in 30d

Description

Hi,

Could you add a Safe Delete Dirs option to allow me to specify deletion of files outside the current folder Gruntfile.js is in?

I want to be able to run Gruntfile.js in a subdirectory of where I want to actually distribute files and delete files.

The force:true is way too broad and dangerous. I don't want to run scripts that are given the ability to delete any file on my machine that I have ownership on. However, the subfolder only restriction is way too strict. I also don't want to have to only delete files under the folder where Gruntfile.js is at. I want to be able to specify the additional trusted folders for delete in just one place in the Gruntfile.js.

I really must be able to set my distribution folder above the folder containing Gruntfile.js which means I need to be able to delete files in a directory above Gruntfile.js yet I don't want to set force:true which gives grunt control over all directories on my machine when I mis-type a directory path. I need to be able to delete the files in my ../webdist directory near the beginning of my grunt execution.

The structure I want is like this:

```
root
└── websrc
├─ Gruntfile.js
├─ package.json
└─ node_modules
└── web
├─ bower_components
├─ css
├─ sass
├─ scripts
└─images
└── webdist
├─ bower_components
├─ css
├─ scripts
└─images
```

I want to execute grunt in the `websrc` subdirectory yet I want it to be able to cleanup files in the `../webdist` directory.

I'm trying to find a way to keep grunt code separate from server-code. Both Grunt frameworks and the server frameworks assume that they are in the directory immediately above the web directory which makes for a confusing merger of files and directories at that level. I'd like to have a separation of concerns. It makes updates and commits confusing too when both frameworks have to share the parent directory to the web directory.

It is really messy to merge the main directory of a Yii PHP application with a Yeoman-Grunt front-end because they both assume they are the direct parent of the web directory. It becomes dozens of directories without clear ownership. I'd like to separate them out so that Grunt stuff goes in one directory and Yii PHP stuff in another. The best organization would be for Grunt to have its own subdirectory that could modify a peer directory.

So I tried setting up grunt and Yeoman this way. It almost works except that the grunt script cannot delete files in a peer directory to the directory the Gruntfile.js is in.
## Need Configurable Safe Delete outside current Gruntfile.js folder

I don't want to use the force:true command or option because if I mis-type something then I will blow away a large chunk of files on my machine. I just cannot take the risk of having force:true. It is a shame because I know exactly which directory I want to allow writes on yet there is no way to add additional directories to the rules throughout the grunt plugins that prohibit deleting files outside the directory the Gruntfile.js is in. I'm tempted to branch and custom code the plugin myself but could take quite awhile. The force:true option does not give me the ability to specify additional trusted directories that I'm allowed to delete files in. This would be a way of defining safe delete.

I wish there were a forceDirs: ['../webdist'] option that would loosen the grunt rule that doesn't allow deleting outside the current directory.

```
forceDirs: ['../webdist']
```

Contributor guide

Open the contributing guide

Research direction

Start by tracing the safe-delete handling behind the Gruntfile.js force:true option and review how task paths are checked. Define the behavior for a configurable forceDirs option such as ../webdist, including path mistakes and multiple trusted directories. Done means deletion is allowed only within configured directories while the existing safer default remains protected.

Written by the indexing model from the issue text.

Assessment

Tech stack
javascript
Domain
security, tooling
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.