You can allow only reading or only writing for files and you can also define what domains are allowed.
In Deno, all permissions would still propagate down to the dependencies.
(version 1)
(deny default)
(allow file-read*
(subpath "~/Downloads")
)
(allow network-outbound
(remote tcp "localhost:80")
)
(version 1)
(allow default)
(deny network*)
# start an airgapped shell, and play around in there..
sandbox-exec -p "(version 1)(allow default)(deny network*)" bashI once ran a simple grep in some of my node projects - most of them had a jonschlinkert package in node_modules, certainly not through any (direct) choice of my own.
> It exists.
What is a bit worrying though is that he is an active member and contributor to TC-39. Meaning that this kind of community hostility is very much alive among the people who rule JavaScript.
8 years later and despite much support for the `.node-version` file.
Someone else started using the .node-version file years ago, and because all open source packages won't form a committee to standardize this file, nvm will not support it.
They have a lot of hills. JS Private Properties was another.
Dogpiling on someone deep in an HN comments tree isn’t exactly the classiest thing but…never having interacted with him myself, I’ve been harbouring this low-grade antipathy towards him - nothing unhealthy, just a groan whenever I see his name on GH - for years now, and it’s cathartic and almost gratifying, given his prominence in the community, to feel seen like this. Thank you.
I think we as a community really need to have a conversation about ljharb and his role in the future of our industry. If he was only a library maintainer, that would be one thing, we could just move on, find workarounds, alternatives, etc. But his involvement in TC-39 makes him one of our rulers in a non-democratic structure. That makes this different.
It’s like they didn’t want to become Python 2/3, and then did the absolute worst possible alternative.
It is beyond frustrating that it’s up to individual package authors whether or not their package supports ESM or CommonJS.
And yeah, it’s a pita when one of your downstream dependencies decides to go ESM only, and breaks your entire friggin chain of stuff that depends on it being CommonJS.
But what is the issue here is the stubbornness of the maintainer and his unwillingness to accommodate a very sizable portion of his user base. The industry is moving on, and as a TC-39 member he should be aware of where the community is moving as well as show some empathy with his users.
Thinking of being the change I want to see in the world.
...
if (!Number.isSafeInteger(n)) {
throw new Error('value exceeds maximum safe integer');
}
...I mean we're talking FizzBuzz secret sauce here. This must be total black magic for a catastrophic percentage of programmers
Someone made the decision to use that and someone thought using stuff made by a person's who makes those kinds of decisions was a good idea and so on.
You can git blame dependencies all the way down and research the parties involved. I've done it, built tools for it even.
A stack of people who make bad decisions doesn't make good software.
/*!
* is-odd <https://github.com/jonschlinkert/is-odd>
*
* Copyright (c) 2015-2017, Jon Schlinkert.
* Released under the MIT License.
*/
'use strict';
const isNumber = require('is-number');
module.exports = function isOdd(value) {
const n = Math.abs(value);
if (!isNumber(n)) {
throw new TypeError('expected a number');
}
if (!Number.isInteger(n)) {
throw new Error('expected an integer');
}
if (!Number.isSafeInteger(n)) {
throw new Error('value exceeds maximum safe integer');
}
return (n % 2) === 1;
};
Something as simple as this can end up being neither even or odd.
(0.1 + 0.2) * 10Basically it helps dealing with all the typing problems of Javascript, and also fitting into functional programming paradigms.
He's not even a technical guy but has a background i marketing and is directly trolling various Github issues :
https://news.ycombinator.com/item?id=28661094
I've always wondered why node-modules and npm required such an insane amount packages so quickly, and now i know why, people like him that use their 10.000 ridiculous packages to boost their career or do whatever self serving community destroying thing they can think off that day.
There really should be a way to ban people doing this shit.
As some people mentioned, most of the usage of is-even is by tools made by this person.
But the other part is that, he made quite a few development tools for beginners that scaffold new projects and pull lots of his packages as dependencies (especially the handlebars helper), which heavily inflates the number of "Dependents" in NPM.
The other issue is that, in the past, he managed to include some of his less-useless packages in some semi-popular tools.
https://npm.anvaka.com/#/view/2d/jest
You can install with the --ignore-scripts flag. Or set the option globally in your npm config file.
???
There is. It's called "doing nothing."
It takes work to add a dependency to your project; they don't spring out of nothing.
It looks like he came from a non-technical background, and is trying to make the language more noob friendly.
Compare the pair:
if isEven(n) { }
if (n % 2) == 0 { }
I guarantee you my wife would have no idea what the second snippet even means.
The problem here is introducing separate dependencies for each of these tiny functions. Dependencies are code that you haven't written, but are still your responsibility. For a lot of things, that's a good tradeoff: if you don't have the expertise in a specific area, or if you can offload work to a dependency that you trust, that's great. But for micro dependencies like this, it's usually a bad deal - you don't get anything in return (seriously, how hard is it to write your own isEven function?) but you have to rely on a third party to be secure, to not push anything accidentally broken, to not change the API, etc.
(I think it's also worth pointing out that your wife is not a paid programmer. Software development should be accessible, but this isn't the only goal, and I think it's reasonable to assume that most programmers either understand the n%2 idiom, or know enough to be able to find help on the subject.)
I think the criticism comes from the fact it is hard to avoid driving over badly designed bridges or avoid wasteful dependencies in the Javascript ecosystem due to the way the package management is organised, and it is felt this specific person contributes a lot to that problem.
I have no knowledge of this person, but I often avoid Javascript and NPM for exactly that reason. I'm hopeful of Deno though to fix some of that mess.
There's a limit though! I think up to about 10% pineapple by weight is reasonable for a Hawaiian, if you choose 0 or 20% then we'll have no issue. If you went to 30% I don't think I could stop myself writing a libellous remark on hn. Anything about 50% and I would be morally forced to denounce you to the proper authorities. About 80% is where the nightmares begin.
https://github.com/jonschlinkert/ansi-reset
https://github.com/jonschlinkert/ansi-bold
https://github.com/jonschlinkert/ansi-dim
https://github.com/jonschlinkert/ansi-italic
https://github.com/jonschlinkert/ansi-underline
https://github.com/jonschlinkert/ansi-inverse
https://github.com/jonschlinkert/ansi-hidden
https://github.com/jonschlinkert/ansi-strikethrough
https://github.com/jonschlinkert/ansi-black
https://github.com/jonschlinkert/ansi-red
https://github.com/jonschlinkert/ansi-green
https://github.com/jonschlinkert/ansi-yellow
https://github.com/jonschlinkert/ansi-blue
https://github.com/jonschlinkert/ansi-magenta
https://github.com/jonschlinkert/ansi-cyan
https://github.com/jonschlinkert/ansi-white
https://github.com/jonschlinkert/ansi-gray
https://github.com/jonschlinkert/ansi-grey
https://github.com/jonschlinkert/ansi-bgblack
https://github.com/jonschlinkert/ansi-bgred
https://github.com/jonschlinkert/ansi-bggreen
https://github.com/jonschlinkert/ansi-bgyellow
https://github.com/jonschlinkert/ansi-bgblue
https://github.com/jonschlinkert/ansi-bgmagenta
It checks out, sales/consulting folks are pretty infamous for their tendency to abuse metrics. The metric here is npm downloads and Github stars.
The strategy does mean that he's _technically_ not inaccurate in claiming this on his LinkedIn -
> NASA, Microsoft, Google, AMEX, Target, IBM, Apple, Facebook, Airbus, Mercedes, Salesforce, and hundreds of thousands of other organizations depend on code I wrote to power their developer tools and consumer applications.
I encountered this type a lot in college consulting groups, it's a little funny seeing one make their way to the OSS community.
What would be the argument for this? It's my understanding that the lack of a default runtime is considered a strength
This dude is counting each one as a project hahaha
`function(val) { return val != null && typeof val === 'object' && Array.isArray(val) === false; }`
But honestly, having seen "TypeError: Cannot read properties of null" enough times, I give it a pass.
https://npm-stat.com/charts.html?author=jonschlinkert paints a pretty crazy picture
- package searches will show these packages due to the inflated usage from transient deps.
- installs are slower due to the package noise.
- increased attack surface when they are used
- cultural normalization of throwaway packages
Probably more.
In addition abstraction of trivial checks, makes it harder to see the limitations of said routine. How well does it work on numeric strings? How well on large numbers where float properties cause issues?
function yes { while true; do echo "${1:-y}"; done } /*!
* is-even <https://github.com/jonschlinkert/is-even>
*
* Copyright (c) 2015, 2017, Jon Schlinkert.
* Released under the MIT License.
*/
'use strict';
var isOdd = require('is-odd');
module.exports = function isEven(i) {
return !isOdd(i);
};Now looking at the source, that package may make sense if figuring out whether something is a number type in JS is really that cumbersome. (Though I'd expect that there is a more generic package that covers the other built-in types as well.)
Also since isNumber treats strings that can be converted to a number, a number, it can yield weird results since adding two strings will naturally just concatenate them. So e.g.:
const a = '1';
isNumber(a); // returns true
const b = a + a; // Now you have a string in b: '11'
[1]: https://github.com/mickael-kerjean/nulll
[2]: https://news.ycombinator.com/item?id=17072675
[3]: https://github.com/mickael-kerjean/nulll/blob/master/test.js
[1] https://github.com/mickael-kerjean/nulll/blob/master/index.j...
The initial function should start with checking for special cases NaN, infinities, 0 and -0, then do (may not be valid JavaScript)
if((x++ === x) && (x—- === x)) printf("even\n");
isOdd = true
neg = x
pos = x
while(true) {
if(neg++ === 0) break;
if(pos-- === 0) break;
isOdd = !isOdd
}
This is good defensive programming. It avoids doing a tricky division by 2.0 that might be buggy (I don’t think https://en.wikipedia.org/wiki/Pentium_FDIV_bug was affected, but who knows what other FPUs do?)
...
https://developers.urbit.org/reference/nock/definition
> The reader might wonder how an interpreter whose only arithmetic operation is increment can ever be practical.
> The short answer is that a Nock interpreter doesn't have to use the algorithm above. It just has to get the same result as the algorithm above.
It was submitted in HN too - https://news.ycombinator.com/item?id=16194932
'use strict';
const isNumber = require('is-number');
module.exports = function isOdd(value) {
const n = Math.abs(value);
if (!isNumber(n)) {
throw new TypeError('expected a number');
}
if (!Number.isInteger(n)) {
throw new Error('expected an integer');
}
if (!Number.isSafeInteger(n)) {
throw new Error('value exceeds maximum safe integer');
}
return (n % 2) === 1;
};is-even (https://www.npmjs.com/package/is-even?activeTab=dependencies) pulls is-odd.
is-odd (https://www.npmjs.com/package/is-odd?activeTab=dependencies) pulls is-number.
sigh
(Alternatively, perhaps odd numbers are actually much rarer, leading to them having a higher market value, and thus more interest in discovering them.)
'use strict';
var isOdd = require('is-odd');
module.exports = function isEven(i) {
return !isOdd(i);
};
I may be misremembering his meaning, but I remember thinking it was an interesting idea. It wasn’t obviously a terrible idea. I thought it would be like the Clojure standard library on steroids, especially if it was coordinated and vetted by a decent team.
But alas, NPM has proven it otherwise.
But have a look at the Unison language https://www.unison-lang.org/docs/the-big-idea/ , that has such global registry but addresses each function by a hash of its syntax tree, and thus sidesteps the issue.
You either accept updates of third party packages, with little to no vetting of your own, and get fixes "for free" or… you don't.
There's no middle ground: the only way to save effort is to trust others.
With Joe's idea everything is up front and part of the language and not a bulletin board of packages near the checkout line at the git supermarket. This way simple stuff like isint() can make its way into the languages official standard library. This should eliminate the uncertainty of 3rd party packages maintained by a random number of individuals that can be taken down or tainted at any time.
Maybe if NPM required all package maintainers to use a namespace, the global is-even package name could resolve to the most-used fork.
So for an import like:
import isEven from 'is-even'
npm install --save @christophilus/is-even
npm install --save is-even
"You wanted a banana but what you got was a gorilla holding the banana and the entire jungle."
(originally on object oriented programming)