Currently the static resources we use are part of a web project in Visual Studio. There are certain files in the project that we want locally that we don't want being deployed to production. We manage this by using the .csproj file and seeing if a file is mark as "content" or "none" etc. (If it's marked as "none" it doesn't get pulled on the deploy).
This works great however we are moving our development out of Visual Studio and into a more Javascript friendly IDE. However if we add or delete files we still need to go back to Visual Studio and update the .csproj file to ensure that production won't get out of sync and that the build won't break.
This got me thinking, as we are implementing Node/Grunt if there's a plug-in of sorts that handles kind of the same thing -- a whitelist/blacklist kind of approach that the server could look at and decide which files to pick up and which ones to leave.
I've tried googling around but I'm not having much luck in figuring out exactly how to phrase it and I'm hoping someone here has any idea on how this can be done. I'm also willing to hear any other better ways of perhaps handling this issue. That in environment agnostic.
Grunt comes with built-in file filters. You can filter anything, it's very powerful. I can't offer a specific solution without seeing your Grunt tasks, but here is an example of different exclusion patterns with the
grunt-copy
task:Grunt uses node-glob so you may want to explore the documentation there to learn about different patterns.
I will also mention that there are plugins to perform string replacements on any file (eg. grunt-replace). With something like that, you can modify your
.csproj
file automatically to add/remove files based on your Grunt filters (or vice versa).Please excuse the anecdote, but as a former .NET developer myself who relied on Visual Studio to handle everything for me, I was initially intimidated by the complexity and apparent frailty of Node.js processes. My message to you would be don't get intimidated, once I became comfortable I realized I had control over every aspect of the build process and was no longer at the mercy of VS. It was the most liberating moment of my career and I haven't looked back.