Update plist parser (and fix package-lock)

[mathiasvr]

Tested on macOS 10.11.6, producing identical Info.plist when packaging.

This PR is blocking PR #1484.

[mathiasvr]

This PR also adds package-lock.json and changes the depcheck test script.

Here's the story:

• We didn't use to have a package-lock.json, but one was included in an old PR, and at the time the CI used npm install and passed.
• The PR was recently merged, but unfortunately this means that package.json and package-lock.json on the master branch is out of sync.
• Now, when a package-lock.json file is present, the CI uses npm ci (a variant of npm install) which automatically fails if the lockfile is out of sync.
• At the same time, the depcheck tool for some reason thinks standard is unused when installed with npm ci instead of npm install
• To avoid failing the CI tests, this PR includes a proper package-lock.json and updates depcheck to ignore standard

...and that's the reason for the changes. 😄

As an alternative, this could have been fixed by removing the package-lock.json file.

[Borewit]

What about using yarn instead (and adding a yarn.lock)?

If you agree, I will open new PR for that.

First fix what we have.

[Borewit]

LGTM

[mathiasvr]

@Borewit What are the benefits of switching from npm to yarn for this project?

[Borewit]

What are the benefits of switching from npm to yarn for this project?

I am big opponent from every NPM module which require to be installed globally. You need a very justification to break out of your module scope to be installed globally, and need be non intrusive towards any other module. I noticed that yarn is close to be part of the from the core node & npm distributions. Yarn is probably, which has a good reason to be part of your global "toolbox".

Why?

1.) As developer I experience yarn more reliable in installing / updating the dependencies after running yarn install, as a bonus it I believe it is faster. We all know we run into certain point where we have to delete node_module, my impression is that with yarn is more strict in translating the dependency requirements into installing required dependency, and is much more unlikely you run into that situation (but only if use yarn solely to take care of the dependencies). Jumping from one branch to another, this can be huge benefit, which we do on this project with PR's coming from all directions.

2.) Yarn is more strict in the interpretation of version requirements, therefor it is less likely your code breaks due to some update which was not there before. Which improves configuration management control.

Draw-backs?

Sure, different character. Due to strict interpretation of the version, you need to pursue update versions more often, it doesn't automatically update package.json with patched version after an install.

Give it try yourself, you will have to get used to the command arguments which are a bit different.

[mathiasvr]

I think you should create an issue, or maybe a PR if you're up for it, where we can discuss this and get some feedback.
I haven't used yarn that much, but in my experience you also get all of these features with the newest version of npm and a lockfile, maybe except for fast installs.

[sibiraj-s]

Adding to @Borewit .

1. Yarn gives more reasonable logs than npm.
2. Definitely cleaner UI in terminal than npm
3. Yarn handles poor internet connections well.
4. and more like (workspaces, which is not needed here. plus extra)

The One thing that npm has and yarn doesn't is audit. also it is on its way. yarnpkg/yarn#6409

I think you should create an issue, or maybe a PR if you're up for it, where we can discuss this and get some feedback.

As said can be discussed on new Issue/PR

[Borewit]

@feross Can you please consider lowering the number of approvals back to 1? It takes way to long to get PRs approved.

Merged by piggybacking on PR #1042.