This can be a perfect alternative for @npmcli/package-json usage in React Router without much changes to the current code

• https://github.com/remix-run/react-router/blob/a4644d37e4b891486e094479bc7c33dd538dd7d5/packages/react-router-dev/cli/commands.ts
• https://github.com/remix-run/react-router/blob/a4644d37e4b891486e094479bc7c33dd538dd7d5/packages/react-router-dev/config/config.ts
• https://github.com/remix-run/indie-stack/blob/56abb93bf81f635b574d9ca23eed05602699458a/remix.init/index.js
• https://github.com/remix-run/blues-stack/blob/7390646d6f3b6e6cb7ef722e4b61cdbffb997afc/remix.init/index.js
• https://github.com/remix-run/grunge-stack/blob/c25307668648b4944e5cd7815c78c098d67ea322/remix.init/index.js

@43081j @pi0 What would you think about convenience methods like removePackageJSONScript btw?
This could replace code like seen in https://github.com/remix-run/grunge-stack/blob/c25307668648b4944e5cd7815c78c098d67ea322/remix.init/index.js#L51-L64

But I would understand if you con't want to add that, as that could lead to a lot of PRs/requests to add others as well

we could possibly change the updatePackageJSON method to accept a function like this:

updatePackageJSON('.', (pkg) => ({
  scripts: {
    ...pkg.scripts,
    build: "foo"
  }
}));

@43081j That could definitely be helpful, but in the example given that would still result into

updatePackageJSON('.', ({ scripts: { "": _scriptToRemove, ...scripts } }) => ({
  scripts,
}));

And I actually wanted to avoid doing the destructing myself with a convenience method like removePackageJSONScript 🙈

i think in those cases we should just support undefined:

updatePackageJSON('.', {
  scripts: {
    scriptToRemove: undefined
  }
});

this is already supported for top level keys, but not sub keys

@43081j Sounds a good alternative if you ask me!

Hey thanks for PR! I just had a chance to read through.

updatePackageJSON looks very promising util we can start with.

Supporting the second argument of updatePackageJSON to be a callback originalPkg => newPkg might be useful for writing all transforms based on it (similar to codeup.updateJSON - example usage)

We could have a followup to add some utils like addDependency, etc, but i guess the list might go on for all pkg.json fields. To fix DX issue of assigning default empty fields, maybe we can give a wrapper Proxy(pkgJson) to update callback so if users assign pkg.dependencies.foo and dependencies is undefined, proxy can auto assign a default object.

Also landed support for package.json5 and package.yaml (#234). Simplified updsatePackage could be replicated if we keep it simply as one updater function.

We could have a followup to add some utils like addDependency, etc, but i guess the list might go on for all pkg.json fields

@pi0 I agree though that we should be careful not to add utilities for all package.json properties.
But having (a couple) convenience method(s) like addDependency would be beneficial imo as that would also sort dependencies list (so not just a basic Object.assign), just like @npmcli/package-json` is doing

Updated utils to match #234 functionality we also talked with @43081j to only land updatePackage with a callback to keep it most flexible. add/remove utils might be added in the future.