Gulp woes

[wpears]

Gulp is something of a pain point, especially requiring a global install separate from this project. Here's some possible actions paired with the problems they solve:

1. Remove Gulp

• Gulp is somewhat duplicative with webpack & npm scripts. We'd never encounter problems with gulp if we wholly remove it from the project.

2. Use the local gulp binary via an npm script

• Rather than requiring a global install of gulp-cli, we can just create a gulp npm script that runs gulp --, which is then invoked with npm run gulp build, npm run gulp clean, etc.

3. In a pre-install step, add ./node_modules/.bin/ to the users path if it doesn't exist there already. This is kinda intrusive and could be a pain point because it isn't super clear what's going on, but would allow local gulp to be run automatically without having to wrap the calls as npm scripts.

Thoughts? @contolini @jimmynotjim @anselmbradford @cfarm @virginiacc @ascott1 @mistergone @Scotchester

[anselmbradford]

This thread may be worth a browse on the topic https://twitter.com/brad_frost/status/1004366863764246533

If we had something like https://github.com/cfpb/capital-framework/tree/canary/scripts/npm for (1), I wouldn't be against it. My understanding is webpack wouldn't be able to do the task running part of our setup, like running binaries for our tests and such, right? The downside is the npm scripts become totally custom without leveraging gulp plugins (though those can be a hassle anyway).

(2) Sounds like kind of a pain, but reasonable if it eliminates a global install, and it would be the lowest lift it looks like and could be done as a pathway toward (1).

(3) Sounds too intrusive, but is it possible to set something like this up for the terminal session via settings in .env?

[Scotchester]

I concur with Ans's thinking that 2 is a reasonable mid-term solution. I'm skeptical that straight npm and webpack scripting will be robust/understandable/straightforward enough to transition to that immediately.

[wpears]

Yeah (2) is my preferred solution, especially shorter term. It also wouldn't preclude running things exactly as they are now, just adds an option that would remove the need for the global install.

For (3), exporting to the PATH would only be for that session actually, but I agree that it isn't exactly preferred. Also, setting it on build would require an npm script anyway (cause you couldn't set it every build as part of gulp if gulp can't be invoked because node_modules/.bin isn't in the PATH).

[jimmynotjim]

I'd love to see us move to 1, but 2 is a better fix short term. @wpears did you publish your test branch?

[contolini]

1 is hard, 3 is brittle, 2 is quick and easy. I vote for 2!

[wpears]

#4256