We don't need a fancy _"portable (Windows/Linux/macOS) implementation
of Unix shell commands on top of the Node.js API"_, we just want to run
a simple script. Replacing with using stdlib `child_process.spawnSync`.
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
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).
I noticed that the development README suggested using multiple console
windows/tabs for a good development experience. Using the package `concurrently`,
we can streamline that and require only one window with output for both watch processes:
Co-authored-by: Ronan Jouchet <ronan@jouchet.fr>
1. Fix (broken since 2016): Notifications broken by lambda constructor
2. Fix: `--processEnvs` broken by additional processEnvs object, the result was:
`processEnvs: {processEnvs: {...}}` which caused the conversion of the inner object into string `[object Object]`, no nesting allowed there probably. Compatibility introduced.
3. Fix: package.json missing `prepare` (or even prepublish), which breaks using as git dependency.
As documented in https://github.com/jiahaog/nativefier/issues/923#issuecomment-599300317 ,
- #923 is caused by installing placeholder app deps at nativefier
*install* time, with yarn (8.0.2) or npm (8.0.3). This is new in
Nativefier 8.x, for the motivations behind it, see
https://github.com/jiahaog/nativefier/pull/898#issuecomment-583865045
- During testing, I did test global installs, but never to a
system / non-user-writable path (my `$npm_config_prefix` is set to
`"$HOME/.node_modules"`)
- But without such a config and when installing globally to a
non-user-writable/system path with `sudo npm i -g nativefier`,
- Installation of nativefier core works...
- ... but then `postinstall` tries to do its job of installing
app deps, and fails in various OS-dependent ways, but all about
access rights.
I suspect that, although main nativefier install runs as `su` with
access rights to system paths, `postinstall` scripts are run *out*
of `su`.
That would make sense for security reasons: out of hook scripts,
npm knows exactly what will be touched in your filesystem: it's the
static contents of the published tarball; a postinstall script with
sudo rights could do nasty dynamic stuff. So, although I don't see
any mention of that in
[npm-scripts docs / hooks](https://docs.npmjs.com/misc/scripts#hook-scripts)
and I haven't dug npm/cli's code, I can understand it.
So, reverting back to `webpack`ing the placeholder app, as done pre-8.0.
