In un ecosistema Microsoft (ad esempio progetti WebForms / MVC / WebAPI VisualStudio) perché dovrei affidarmi a un gestore di attività esterno per file JavaScript come Grunt se ho già MSBuild a mia disposizione come sistema predefinito di esecuzione / attività?
Quando ho visto per la prima volta un grugnito in azione, mi sono chiesto perché venisse usato, perché mi sembrava di poter fare quello che stava facendo affidandosi direttamente alle attività di MSBuild. Di solito preferisco gli strumenti centralizzati per fare lo stesso tipo di lavoro, e presumo che sia MSBuild che Grunt stiano facendo sostanzialmente tipi simili di azioni: l'esecuzione di attività contro / usando i file come input. Tutti i file javascript per questi progetti Web sono già referenziati in csproj in ogni caso, quindi sono automaticamente parte del processo di compilazione. Usare MSBuild per elaborarli mi sembra molto più naturale che iniettare una nuova struttura nel mezzo per farlo.
Credo che usare un altro framework per eseguire lo stesso tipo di lavoro che già si fa con un framework esistente sia una decisione sbagliata poiché aggiunge nuove dipendenze non necessarie che devono essere apprese / padroneggiate dal team. Inoltre, sappiamo tutti che più parti mobili equivalgono a maggiori possibilità di guasti in generale. Inoltre sostengo che MSBuild si integra già bene con Visual Studio, mentre grunt richiede estensioni o lavoro da riga di comando manuale per l'esecuzione.
C'è una ragione specifica per cui MSBuild non è stato sfruttato per il tipo di lavoro che Grunt fa al giorno d'oggi?
Capisco che sono ecosistemi completamente diversi e capirebbero totalmente qualcuno che usa Grunt su un tipo di progetto open source non Microsoft, ma non ha senso che sia diventato uno standard per le applicazioni .Net visto che hanno già uno strumento per fare solo i tipi di compiti che fa.
Non fraintendetemi, capisco l'argomento "ci sono molti plugin disponibili", ma per me è simile a dire che dovremmo tutti smettere di usare TFSBuild e migrare a Jenkins perché ha più plug-in disponibili. È un argomento valido, ma non tanto da eliminare completamente i punti di forza di TFSBuild in alcune situazioni.