node-gradle / gradle-node-plugin

Gradle plugin for integrating NodeJS in your build. :rocket:
Apache License 2.0
599 stars 117 forks source link

Question: Is there a smooth way to use different args with npmInstall in different situations? #300

Closed mpassell closed 6 months ago

mpassell commented 7 months ago

I'm hoping that I've just missed an obvious way to do something. Most of the time I want a task to depend on npmInstall, I'm happy to have it just invoke npm ci. However, when preparing my node_modules directory to be scanned for vulnerabilities, I wan't to exclude dev-only dependencies using npm ci --omit=dev. Is there an easy way to do that? I'd be fine with having two different instances of npmInstall task and setting up a dependency on the right one based on which of my tasks I'm in. Would that make sense?

mpassell commented 7 months ago

Oh... would it be as simple as doing something like the following (Kotlin syntax):

tasks.register<NpmInstallTask>("npmInstallNoDev") {
    args.set(listOf("--omit=dev"))
}

Update: that worked! 🎉 I'd be willing to close this, but would it make sense to document it explicitly somewhere? If you feel like the existing docs already cover it, it would be great to add a link here.

deepy commented 7 months ago

Having multiple NpmInstallTask should be fine 👍 But there's some things you might want to consider given that they both operate on the same state

Other tasks might have a dependency causing npmInstall to run (before or after the --omit=dev) Do you use remote or local caches? Does --omit=dev have any effect on your distribution?

This to me looks like something that runs in its own CI pipeline and if so it sounds like it should be fine, but if not it might be worth introducing a configurable property or creating a temporary working directory for running the second npm install and security scan in

mpassell commented 7 months ago

Thanks! Good guess on the last part. Yes, it runs in its own CI pipeline, so it shouldn't result in any side effects for other builds. I like your idea of making it configurable (property, env var, etc.) though.