Persist unchanged dependencies

[maticzav]

Is it possible to only override the selected dependencies without removing unlisted ones?

[sindresorhus]

I don't understand what you're asking. Can you provide an example or elaborate?

[maticzav]

@sindresorhus sure thing. Consider the example below.

{
  "name": "project",
  "dependencies": {
     "a": "1.0.0"
  }
}

I would only like to add/override a dependency. Currently, to my understanding, it's only possible to construct an object of all dependencies and add/modify existing ones before committing changes to the package.json. However, would it be possible to only "add" { "b": "1.0.0" } and even though a is not specified have it in the package.json?

If I remember correctly, this was important to me because otherwise, I have to construct an abstraction myself which firstly reads the dependency then updates it and only later commits changes which, as a consequence, increases the number of tests on developers end.

[sindresorhus]

Yeah, we could expose some utility methods for common package.json modification needs, like writePkg.addDependencies([{name: 'a', version: '1.0.0', type: 'dev'}]);, writePkg.removeDependencies(['b']);.

[tommy-mitchell]

@sindresorhus should consecutive calls be able to preserve arbitrary fields in a package.json? e.g:

await writePackage({name: 'foo', version: '1.0.0'});

{
	"name": "foo",
	"version": "1.0.0"
}

await writePackage({version: '2.0.0', license: "MIT"});

{
	"name": "foo",
	"version": "2.0.0",
	"license": "MIT"
}

---

Currently, package.json after the second call would be:

{
	"version": "2.0.0",
	"license": "MIT"
}

I had been trying to use write-pkg to test np this way, since I (incorrectly) assumed from this line in the readme that this was already the actual behavior:

Preserves the indentation if the file already exists.

Maybe the current behavior could be moved to an overwritePackage function?

[sindresorhus]

No, I would expect writePackage to overwrite. We could instead add a updatePackage method for merging.

[tommy-mitchell]

Thinking it over more, updatePackage could take the place of addPackageDependency. If someone wanted to remove a dependency, they could use a combination of read-pkg and dot-prop, or something similar.

[sindresorhus]

I stil think addPackageDependency would be a nice convenience.

[tommy-mitchell]

addPackageDependency could easily be a wrapper around updatePackage. What about removePackageDependency thought? Would we want to include that?

[sindresorhus]

addPackageDependency could easily be a wrapper around updatePackage.

Yep

What about removePackageDependency thought? Would we want to include that?

Makes sense to have the inverse of adding, yes.