Closed moea closed 7 years ago
After thinking about this quite a bit. I am OK with this feature. I don't think it is ideal for a lot of people though. It might enable you know, but would an alternative be better?
I'm starting to think that lein-npm should have an option to persist package.json
. If package.json
is persisted, many problems are solved, but it means other programs might modify package.json
too. It is for users who want to do both (persist and modify package.json
with multiple programs) that I am not sure how to support. Maybe that subset is small enough they can produce their own tools with the feature you've created in this PR.
Do you have any feedback on simply supplying an option to persist package.json
? Would that work better for you?
Ryan,
My particular case is generating a package.json
for Elastic Beanstalk Node deployments. For local development, I rely on the default/ephemeral behaviour with no issues, and am occasionally calling dump-package
from what's currently a shell script, before moving the output into a zip file.
If persist means "leave around, but overwrite next time", it'd be equivalent functionality for the purposes of what I'm doing - if it'll also help solve related problems, let me know, and I'll send over another PR.
To summarize, there are basically three options that we can pick one or more of:
project.json
.:npm {:persist true}
option to overwrite any package.json
and not delete it when whatever npm command is run is complete.:npm {:merge-deps-only true}
option to specify that package.json is maintained by the user in some other way and only to merge in jar based dependencies into the package.json
.Who wants what? :)
Just to be clear, I am leaning towards @ScottyB's solution in #38.
Addresses #24 - I didn't add an output paths/dir option - the file is written at the project root, like the ephemeral
package.json
(and so will prevent furtherlein npm
operations so long as it remains there).This covers my use case - more than happy to expand.