is-odd VS flatpak

Ridiculous as it may be, my guess is that provides a unified way of number checking while avoiding the pitfalls or crazy consequences which could arise from divide-by-zero[1], which I guess might prevent less-experienced folks from tripping up on some of the Javascript gotchas? I'm not really sure. That being said, I have seen those package dependencies in some serious stuff.

Do I agree? I'm not really sure to be honest. Probably not.

[0] https://github.com/i-voted-for-trump/is-odd/blob/master/READ...

[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

it gets worse: https://github.com/i-voted-for-trump/is-odd/blob/master/index.js

So it disappeared and node apps stop building and it was a huge fiasco getting it restored. Just for reference, https://github.com/i-voted-for-trump/is-odd is a current fork of it and it has 34M downloads.

Checks of this extensiveness would be mad for such a simple library. I mean, who would use a library with that extensive checks?

I think that this approach would cut down the amount of JS dependencies significantly. Things like is-even and is-odd come to mind. You don't want another leftpad or colors.js to happen to you and minimising dependencies is the most effective strategy to accomplish that.

So many leaf dependencies I've looked into are no more than a Stackoverflow answer in a JS file accompanied by six or seven metadata files (package.json + typescript files + linter config + readme + git config + ...). This file: https://github.com/i-voted-for-trump/is-odd/blob/master/inde... is downloaded over 400000 times per week (https://www.npmjs.com/package/is-odd) and while I don't have anythimg against the author for publishing a helpers function, I don't see why I would expose my project to risking a supply chain attack for something so minor. Here's another, with millions of downloads: https://github.com/inspect-js/is-date-object/blob/main/index...

I know that these are all downloaded so ofyen because theyre dependencies of dependencies but I'd appreciate it if bigger libraries would provide a vendored version of their packages that just collects these microdependencies instead of wasting npm's time by making it manage these tiny helper files. Don't vendor stuff like React or Vue or whatever framework you prefer but for the love of God don't add a dependency for 50 lines of code. Sometimes copy/paste is the right solution.

$ npm install --save is-odd // https://www.npmjs.com/package/is-odd // This package has about 500k weekly downloads // https://github.com/i-voted-for-trump/is-odd/blob/master/index.js module.exports = function isOdd(value) { const n = Math.abs(value); return (n % 2) === 1; };

I started reading your comment curious about the source code. But I finished reading your comment only more curious. So I went to GitHub's "is-odd" and I've come back to give everyone *is-odd'*s source code in it's entirety. And here it is:

Hopping from one distro to another with a different package manager might require some time to adapt. Using a package manager that can be installed on most distro is one way to help you get to work faster. Flatpak is one of them; other alternative are Snap, Nix or Homebrew. Flatpak is a good starter, and if you have a bunch of free time, I suggest trying Nix.

No, it looks like you have to do it on an application basis.

https://github.com/flatpak/flatpak/issues/2913

Flatpak

> CLI tools do not implement auto-complete themselves. What you are seeing are auto-complete scripts for your shell that make network connections.

nit: This is incorrect. Robust auto-complete scripts call the actual program to provide completions.

That is what Flatpak does. It is Flatpak itself that makes the network connections.

https://github.com/flatpak/flatpak/blob/main/completion/flat...

Not that it would make any differencen if it was implemented in Bash seeing as the Bash script is also provided by Flatpak.

The only performance impact I know of is with the seccomp filter in CPU-bound tasks: https://github.com/flatpak/flatpak/issues/4187

Skimming through the recent comments, there might be a way to optimize some of it.