Юрий Ярош

Если читатать доки - становится понятно что есть опция exclude,
которая принимает строки и регулярки.

var wiredep = require('wiredep').stream;

gulp.task('wiredepWIthoutJquery', function() {
  return gulp.src('index.html')
    .pipe(wiredep({
      exclude: [ /jquery/],
    }))
    .pipe(gulp.dest('./dest'));
});

Нужно
1. Хорошо понимать как масштабировать приложения, как вертикально так и горизонтально. Как на запись так и на чтение. Внедрять различные наукоемкие вещи по потребности.
2. Понимать недостатки всех существующих решений и как их можно разрешить. Как правило 80% всего-всего - банальный CRUD, и в большинстве случаев это тонны копи-постного кода аля "одна табличка - один контроллер" без 3-4 нормальной формы модели БД. Со стороны браузеров тоже очень много нюансов. Нужно понимать все эти проблемы, некоторые из них пытаться решить - привлекать людей и создавать новые проекты и сообщества.
3. Поддерживать реюзабельность, относительно простую поддержку и внедрение всех компонентов системы, внедрять SOA с хорошим покрытием тестами, не пренебрегая профилированием, фаззингом и нагрузочными тестами. Профилировать всё и вся нужно уже с самого начала работ.
4. Правильно расставлять приоритеты и производить детальную выработку всех требований. Очень много времени в пустую тратится из-за неправильно сформулированных требований и плохо подобранные инструменты.
5. Понимать как мотивировать существующий персонал, пытаться понять что побуждает людей к работе и какие у них внутренние цели, как правило деньги людей не мотивируют. Относится ко всем как к "ослам и морковке" очень глупо.
6. Понимать возможные когнитивные искажения и психологические компенсаторные процессы у существующего руководства и коллектива, быть ключевым звеном на пути к их разрешению.
7. Правильно делегировать свои собственные полномочия - иногда на всё это вас не хватит, нужно давать возможность другим решать все вышеописанные вопросы и проявлять инициативу.
8. Нанимать и работать с людьми которые заинтересованы в развитии и перспективах вашего продукта, а не просто "делать что скажут за деньги" - так вы не сможете построить действительно конкурентоспособный продукт.
9. Вдохновение не вечно - люди не смогут постоянно делать одно и тоже, нужно понимать что программисту лучше чувствовать себя художником нежели мясником в цеху рыбообработки.
10. Понимать что названия должности не должны решать как будет работать коллектив - люди должны быть взаимозаменяемы, и они должны уметь анализировать и предлагать варианты решения задач для других. Чем больше мнений - тем точнее сформулированы требования и подобраны инструменты. Зацикливаясь на специализации и должностях - ваш BusFactor всегда будет 1-2, и в сложную минуту это сыграет злую шутку с вами и вашим коллективом.

Если у вас будет подобный опыт организации - для вас не важно будет название вашей должности, вы просто создадите контору в которой всем будет приятно работать. И если вам не отдадут CTO, или около того, я уж и не знаю что там за тараканы в головах CEO и стейкхолдеров.

А вообще дело обстоит так что 80% проектов работают без вменяемого руководства и индивидуального подхода, не имеют жизнеспособной бизнес-модели и MVP, часто продают вакуум, плодят "грибных менеджеров" и "менеджеров-чаек".

Стоит разобраться с существующими антипаттернами и находить их на текущих местах работы, искать пути их разрешения и пытаться объяснить почему подобная деятельность деструктивна.

p.s. мне предлагали CTO, но на практике все обстоит так что организовывать всё-всё приходится с нуля без каких либо гарантий нормального сотрудничества.