Thinking about it again, the user-friendlier `a.x` syntax has one disadvantage
over `^a.b.c`: it doesn't force deps upgrades when they upgrade Nativefier.
`a.x` is fine on initial install, but a user with an insecure dep
(e.g. axios 0.19.0) will _not_ get fixed axios 0.21.1 on upgrading Nativefier.
-> Come back to `a.x` everywhere.
Still not introducing package locks, they're too confusing to new devs.
See https://github.com/nativefier/nativefier/pull/1099#issuecomment-761250232
Not doing anything more complicated (adding macOS-specific code
or adding code always passing an icon), let's instead wait for
Electron to fix the issue.
Rationale for nonsensical major version bump: around Nativefier 8.x,
versions of Nativefier and Electron aligned, by release schedule coincidence.
Since Nativefier has little breaking changes, it was great: as Electron
releases are breaking, Nativefier had no breaking changes, I bumped our
major version on new major Electron, and everything was good.
Except *now*, as I have a breaking change, that would bump Nativefier to
12.x, which would be confusing since we'd still default to Electron 11 :-/ .
-> To keep respecting semver and reduce confusion, bumping Nativefier
version to something far ahead. No it doesn't matter, version
number are meaningless anyway (well, outside of semver, whose
respect is precisely the point here).
Verifies short arguments do not contain an extra dash ( right: `-h`, error: `--h` )
Verifies long arguments contain at least two dashes ( right: `--help`, error: `-help` )
Looking at https://travis-ci.org/github/jiahaog/nativefier/jobs/742333968 ,
I see that @typescript-eslint/eslint-plugin@3.10.1 is being "Found".
I didn't ask for it, and I see that Travis reports in its "cache.npm"
section that
adding /home/travis/build/jiahaog/nativefier/node_modules to cache
creating directory /home/travis/build/jiahaog/nativefier/node_modules
-> Maybe Travis is trying to reuse stuff and we had a leftover ts-eslint@3
in the build machine??? Trying prefixing dev-up with a cleanup
