I'm getting tired of this npm shit
-
@pydsigner said in I'm getting tired of this npm shit:
if (10 > n && n < 20) {
Unless JavaScript has operator overloading since last time I checked, that's the same as
if (n < 10) {
.
-
@kt_ said in I'm getting tired of this npm shit:
comparing string to nothing
What, does
String.IsNullOrEmpty
not work properly in VB.NET on newer versions or something?But yes, you have to use
Is Nothing
instead of== null
and= String.Empty
instead of== String.Empty
but it's not that difficult to remember.
-
@ben_lubar said in I'm getting tired of this npm shit:
operator overloading
Or a way to make a variable have a different value each time it is read.
To be fair, it's not really a good idea to do that — it hurts your brain when you think about the consequences — but it's sometimes useful.
-
var obj = { get prop() { return Math.floor(Math.random() * 10) + 1; } }; console.log(obj.prop, obj.prop, obj.prop);
-
@powerlord said in I'm getting tired of this npm shit:
@kt_ said in I'm getting tired of this npm shit:
comparing string to nothing
What, does
String.IsNullOrEmpty
not work properly in VB.NET on newer versions or something?But yes, you have to use
Is Nothing
instead of== null
and= String.Empty
instead of== String.Empty
but it's not that difficult to remember.It shows how much broken the language is compared to C#. Also, it's easy to introduce a bug this way, if you have to switch between C# and VB.NET a lot. And I've mentioned many more misfeatures and I'd like to add another one of those: passing parameterless lambdas as
Action
.It's a piece of dung, live with it.
-
@aapis said in I'm getting tired of this npm shit:
You say I'm right for the wrong reasons, but you follow that with something that exactly proves my point. You don't want to write it because someone may have done that already. Well guess what, someone has already done everything. All of the problems we work on today have been solved and resolved for decades, yet we keep plugging away because that's not the point of programming or CS in general.
I recently needed a signature scheme which would commit to a number in a way that only the original signer can increase the number, but anyone could decrease it, and I wanted the signature size/verification time to be at most logarithmically-sized in the magnitude of the number. (This was a component of a much larger cryptosystem that I can't go into details right now.)
I'm pretty sure I've solved this, but there is still work to do formally proving correctness and security, getting review, doing the implementation, etc. It's annoying but I figured I had to do it since as far as I was aware I was the first person to come up with this.
But if you have some special knowledge that lets you know that "everything has been solved for decades" please let me know where this repository of knowledge is!
-
@Maciejasjmj said in I'm getting tired of this npm shit:
no other reason than WAARGABLAARGH
wharrglarb is what moves the world. accept this, and the pain will go away
-
var n = { valueOf() { return Math.floor(Math.random() * 10) + 1; } }; if (10 > n && n < 20) { console.log('Ah, that is nice'); } else { console.log('Better luck next time!'); }
No, no need to thank me ... I'll just show myself out now ...
-
@ben_lubar said in I'm getting tired of this npm shit:
@pydsigner said in I'm getting tired of this npm shit:
if (10 > n && n < 20) {
Unless JavaScript has operator overloading since last time I checked, that's the same as
if (n < 10) {
.Yup, that's what you get for attempting Yoda™ Conditions to inequality comparisons.
-
@kt_ said in I'm getting tired of this npm shit:
@Jaloopa said in I'm getting tired of this npm shit:
@kt_ it's C# with different syntax. The only things I particularly dislike are the lack of a ref keyword in method calls and having to remember the different syntax for things like switch blocks
No it's not. lambdas, comparing string to nothing, for loop, shitty case-insensitivity making your code even more unreadable (if the syntax itself wasn't enough).
I honestly seriously hate this language.
VB.NET has lambdas.
Their syntax is just fugly as sin.
-
@aliceif said in I'm getting tired of this npm shit:
Their syntax is just fugly as sin.
Yeah, it's pretty nasty. I tried to stick some lambdas in something I was writing, realised it was horrible and switched to LINQ SQL style syntax
-
@aliceif said in I'm getting tired of this npm shit:
@kt_ said in I'm getting tired of this npm shit:
@Jaloopa said in I'm getting tired of this npm shit:
@kt_ it's C# with different syntax. The only things I particularly dislike are the lack of a ref keyword in method calls and having to remember the different syntax for things like switch blocks
No it's not. lambdas, comparing string to nothing, for loop, shitty case-insensitivity making your code even more unreadable (if the syntax itself wasn't enough).
I honestly seriously hate this language.
VB.NET has lambdas.
Their syntax is just fugly as sin.That's what I was taking about.
-
@coderpatsy said in I'm getting tired of this npm shit:
var obj = { get prop() { return Math.floor(Math.random() * 10) + 1; } }; console.log(obj.prop, obj.prop, obj.prop);
Easier to
return Date.now()
-
@bjolling But then you won't ever have the same value (sans monkeying with system date or multiple accesses in the same millisecond).
Though I should have set the random range to at least 20 to match the discussion.
-
@xaade said in I'm getting tired of this npm shit:
<not_satirical>
I would totally go forif (0 < x < 10)
</not_satirical>
Time to brush up on your Perl 6!
-
@OffByOne said in I'm getting tired of this npm shit:
Time to brush up on your Perl 6!
I hope you meant that as a joke. Did you? Say you did?!
Perl 6 is like that time when the dog and the cat baked the cake. It has every nice feature somebody could think of and the result is completely
indigestibleunimplementable and unintelligible.
-
@pydsigner said in I'm getting tired of this npm shit:
if (10 > n && n > 20) { console.log('hai'); }
: fixed code bug.
No you didn't.
-
@Bulb said in I'm getting tired of this npm shit:
@OffByOne said in I'm getting tired of this npm shit:
Time to brush up on your Perl 6!
I hope you meant that as a joke. Did you? Say you did?!
Maybe.
Perl 6 is like that time when the dog and the cat baked the cake. It has every nice feature somebody could think of and the result is completely
indigestibleunimplementable and unintelligible.I think Perl 6 is a nice academic experiment, but it's not useful for production.
-
@OffByOne My respect for Perl increased.
-
@xaade said in I'm getting tired of this npm shit:
@OffByOne My respect for Perl increased.
My job here is done.
-
@OffByOne said in I'm getting tired of this npm shit:
, but it's not useful for production.
that's not going to stop it being used for production mind.
i mean even brainfuck's actually used for production tasks FFS
-
@accalia said in I'm getting tired of this npm shit:
@OffByOne said in I'm getting tired of this npm shit:
, but it's not useful for production.
that's not going to stop it being used for production mind.
My opinion is not necessarily the same as someone else's opinion. Also, I try not to force others to adopt my opinions.
If someone wants to use Perl 6 for production, let them. The results might be interesting :) Doesn't mean I would ever do that.
i mean even brainfuck's actually used for production tasks FFS
You just made me throw up a little in my mouth
-
@OffByOne said in I'm getting tired of this npm shit:
@accalia said in I'm getting tired of this npm shit:
i mean even brainfuck's actually used for production tasks FFS
You just made me throw up a little in my mouth
you're welcome.
-
@OffByOne said in I'm getting tired of this npm shit:
@pydsigner said in I'm getting tired of this npm shit:
if (10 > n && n > 20) { console.log('hai'); }
: fixed code bug.
No you didn't.
Unfortunately there is some sort of maximum edit time. But yeah, can you tell I'd rather be using Python anyways?
10 < n < 20
done.
-
@pydsigner said in I'm getting tired of this npm shit:
can you tell I'd rather be using Python anyways?
10 < n < 20
done.No love for Perl 6?
-
@accalia said in I'm getting tired of this npm shit:
i mean even brainfuck's actually used for production tasks FFS
I believe CDCK is planning to migrate to BF for 4.0 due to performance concerns.
-
You guys might appreciate this npm shit:
So I subscribed to an issue on the JSDocs repository; JSDocs is basically the number one package for writing inline, javadoc-style comments for javascript, so it's kind of a huge deal. One of their dependencies is upon a github repository for something called taffyDB. The issue I and others have raised is that it requires my build pipeline to depend on upon github, which many workplaces would like to block to prevent people from using unapproved packages (you can't add that to a whitelist for NPM Enterprise as far as I know).
This is the big long writeup of why they can't just move that taffyDB dependency to npm:
I've investigated this issue thoroughly. tl;dr: At this time, I can't find a way to use a TaffyDB package from NPM. Every option I can think of would break ~all JSDoc 3 templates, which is not an acceptable outcome. Please do not comment unless you have a solution that a) I haven't thought of already and b) does not break ~all JSDoc 3 templates.
Here are the gory details for those who are interested, including all the options that I considered:
Background
When JSDoc invokes a template, it passes the doclets to the template as a TaffyDB object. All JSDoc 3 templates expect to receive a TaffyDB object as an argument to their exports.publish method.
JSDoc currently uses a fork of TaffyDB that is known to work correctly with JSDoc. The fork is not published to NPM—it is installed from GitHub when you run npm install.
Almost all JSDoc 3 templates are derived from the default template, which includes the following line in publish.js:
var taffy = require('taffydb').taffy;
As a result, ~all other JSDoc 3 templates include the same line of code. In other words, ~all templates expect that require('taffydb') will work as expected. (The only exception I know of is the Baseline template, which is still experimental and has not been widely adopted.)
Note that this expectation is true even if the template does not list TaffyDB as one of its dependencies. That's because, for historical reasons, JSDoc makes it possible for external templates and plugins to require JSDoc's module dependencies, including TaffyDB, without installing them locally.
Alternative 1: Use the version of TaffyDB on NPM
There are two versions of TaffyDB that are published to NPM as taffydb:
0.0.1: Fails to run.
2.7.2: Affected by the bug typicaljoe/taffydb#114, which causes TaffyDB's isUndefined matcher not to work. The default template depends upon this matcher, which means that ~all other JSDoc 3 templates also depend upon it. As a result, upgrading to version 2.7.2 would break ~all JSDoc 3 templates.
If a new version of TaffyDB were released that fixed typicaljoe/taffydb#114, then it would be possible to use NPM's taffydb module, thus solving the problem. However, TaffyDB is not actively maintained, so this bug is unlikely to be fixed anytime soon.Alternative 2: Use a fork of TaffyDB published to NPM
I published JSDoc's fork of TaffyDB to NPM as taffydb-jsdoc. JSDoc could be updated to
require('taffydb-jsdoc')
instead ofrequire('taffydb').
However, this change would break ~all JSDoc 3 templates other than the default template, because ~all JSDoc 3 templates attempt to
require('taffydb').
One way to work around this problem would be to use an NPM post-install script that creates a symbolic link from node_modules/taffydb-jsdoc to node_modules/taffydb. However, JSDoc used to include a similar post-install script, and users were very unhappy about it—the post-install script created a large number of installation problems.
Alternative 3: Bundle TaffyDB with JSDoc
In the pull request jsdoc3/jsdoc#1202, @popomore suggested bundling TaffyDB with JSDoc in a deps/ directory. However, this approach has the same problem as Alternative 2—it prevents require('taffydb') from working, so it breaks ~all JSDoc 3 templates.
Alternative 4: Stop using TaffyDB
If JSDoc did not use TaffyDB, we wouldn't have to worry about this problem at all. However, migrating from TaffyDB is impractical for a few reasons:
All JSDoc templates expect to receive a TaffyDB object as one of their inputs. We could try to provide an object that behaved like a TaffyDB object, but that would essentially require reimplementing TaffyDB as part of JSDoc.
Even if we solved the previous problem somehow, ~all JSDoc 3 templates would still break, because they attempt torequire('taffydb').
ConclusionFor now, we're stuck with the current system of installing TaffyDB from GitHub.
If you really, really care about being able to install JSDoc from NPM, please put your energy into fixing typicaljoe/taffydb#114 and convincing the TaffyDB maintainers to release a new version with your fix.
-
@Yamikuronue Why can't
require('taffydb')
point at a fixed version? It sounds like the problem is that the only versions published via whatever is “official” have critical bugs, so a fork-and-stuff-you-guys-for-never-fixing-anything is a reasonable approach. But that's just what I'd do, coming at it from the perspective of someone who works with other languages.I'm guessing that the problem lies in how
require
couples to random git repositories out there without any true curation step in-between. That is, it's the same old npm shit that we've covered up-thread…
-
@dkf said in I'm getting tired of this npm shit:
Why can't require('taffydb') point at a fixed version?
You can use
require
in two ways: with a relative path, or with an official NPM package name. The maintainers of taffydb seem to have abandoned the package, so there's no fixed version on NPM. They're using a forked version on Github with apackage.json
that says its package name istaffydb
, just like the real one, but they don't have publish rights to the taffyDB name on NPM, so they can't publish a fix either.@dkf said in I'm getting tired of this npm shit:
I'm guessing that the problem lies in how require couples to random git repositories out there without any true curation step in-between
Any curation that happens would be in an npm dependency anyway. It lets you require things from github as a convenience step ; you used to have to download the file yourself and then depend on it from the local filesystem. The problem IMO is that you can go to NPM with a dependency that is not also in NPM. This is a terrible practice because you can easily end up stuck like this. It's fine for development (I do it all the time; AutoGM depends on a specific branch of sockmafia right now because I've pushed changes I'm still testing to it) but don't publish until your dependencies have as well!
-
@Yamikuronue said in I'm getting tired of this npm shit:
They're using a forked version on Github with a
package.json
that says its package name istaffydb
, just like the real one, but they don't have publish rights to the taffyDB name on NPM, so they can't publish a fix either.But does that mean inevitably that nobody else can maintain the package despite it being abandonware? That is what I'm talking about in terms of curation; it stops people from ending up left in the lurch when the original developers of the dependency bail. (Also, the bailing can happen for all sorts of reasons, including going bankrupt or because the developer got hit by a piece of falling space junk.)
-
@Yamikuronue
Alternative 5: use the latest version available via npm and monkeypatch it with a bug fix :-)
-
Alternative 6:
var Module = require('module'); var originalRequire = Module.prototype.require; Module.prototype.require = function(){ if (arguments[0] === "taffydb") { arguments[0] = "taffydb-jsdoc"; } return originalRequire.apply(this, arguments); };
-
-
@Onyx
Horrible problems demand horrible solutions.
-
@Yamikuronue said in I'm getting tired of this npm shit:
why they can't just move that taffyDB dependency to npm
npm
shouldn't have allowed them to plant themselves in this corner in the first place by insisting that the dependencies are all available in the same repository. That is, it shouldn't be possible to publish a package innpm
repository if it depends on anything that is not itself available innpm
repository.Also, passing a type provided by another package is a great way to plant yourself in exactly this kind of corner. If you pass a type defined by your dependency in and out of your API, you should probably reexport the type or the whole package that defines it exactly to make sure that all dependencies use the same type and the same version of it.
@Onyx said in I'm getting tired of this npm shit:
@CreatedToDislikeThis That's fucking horrible.
They shouldn't have let themselves planted in this corner. But they did and now they'll have to use a horrible solution.
-
@Bulb said in I'm getting tired of this npm shit:
That is, it shouldn't be possible to publish a package in npm repository if it depends on anything that is not itself available in npm repository.
@Yamikuronue said in I'm getting tired of this npm shit:
The problem IMO is that you can go to NPM with a dependency that is not also in NPM. This is a terrible practice because you can easily end up stuck like this. It's fine for development (I do it all the time; AutoGM depends on a specific branch of sockmafia right now because I've pushed changes I'm still testing to it) but don't publish until your dependencies have as well!
@Bulb said in I'm getting tired of this npm shit:
passing a type provided by another package
Javascript. You can't define an interface instead, and the require ecosystem is fundamentally incompatible with DI so you have to hack around it. Have fun!
-
@Yamikuronue said in I'm getting tired of this npm shit:
the require ecosystem is fundamentally incompatible with DI
I knew there was something that was bothering me about it.
-
@dkf The best case here would have been to expose Taffy in the base package somehow, like
JSDocs.db
or something, so the templates could make use of it and the main package could control the version dependency. Which is essentially re-inventing a global singleton.
-
@Bulb said in I'm getting tired of this npm shit:
passing a type provided by another package
You shouldn't ever be thinking in terms of types in Javascript. You're just passing an object that happens to have been constructed from a particular prototype.
-
@Yamikuronue said in I'm getting tired of this npm shit:
Javascript. You can't define an interface instead
Well, interface is just a documentation saying which members you can rely on and on which you can't.
However, it would likely be futile, since the users don't read documentation anyway.
Or one could create a wrapper. However, half of the downstream developers would take it apart anyway, because there is no privacy, so not that much help either, unfortunately.
@Yamikuronue said in I'm getting tired of this npm shit:
and the require ecosystem is fundamentally incompatible with DI
@Yamikuronue said in I'm getting tired of this npm shit:
@dkf The best case here would have been to expose Taffy in the base package somehow, like
JSDocs.db
or something, so the templates could make use of it and the main package could control the version dependency. Which is essentially re-inventing a global singleton.That's what I had in mind. I wouldn't call it global singleton. It is a re-export. You are making the module accessible as if it was your own submodule. Which it effectively is if you are relying on its types.
-
@Yamikuronue said in I'm getting tired of this npm shit:
JSDocs is basically the number one package for writing inline, javadoc-style comments for javascript, so it's kind of a huge dea
@Yamikuronue said in I'm getting tired of this npm shit:
However, TaffyDB is not actively maintained, so this bug is unlikely to be fixed anytime soon.
@Yamikuronue said in I'm getting tired of this npm shit:
convincing the TaffyDB maintainers to release a new version with your fix.
Why not, like, contact NPM and ask them to publish the patched library? Maybe they can meddle in a way that actually fixes something this time instead of breaking the universe.
-
Alternative #5: Redefine what it means to be
taffydb
Set your registry to an NPM Enterprise / Nexus / Artifactory version of NPM and host the fixed version there. This does not fix the world, but it does fix your problem.
Alternative #6: Patch all the templates
Run
patch
orsed
on every template lib you depend on onpostinstall
to changerequire('taffydb')
torequire('taffydb-jsdoc')
. Does not fix the world, but fixes your problem.
-
@svieira Those aren't alternatives for jsdoc, they're alternatives for end users such as myself.
-
@Yamikuronue Ah, apologies, I mis-read what the issue was. Yes, there is no good solution for JSDoc 3 - aside from upping their major version number and not using TaffyDB anymore.
-
As a matter of fact, while we were debating, someone who has the rights to release taffydb backported and released an older version from before the bug was introduced that jsdocs can depend on. So... sure, do that XD
"None of us want to figure out why that bug's there, but here, have an old version instead."
-
@flabdablet said in I'm getting tired of this npm shit:
@cartman82 said in I'm getting tired of this npm shit:
You don't need 17 curried fucking function calls to compare 2 numbers.
This is 2016. You're just a Luddite who fears change. Get with the program.
I tried the program, but I got a "npm package not found" error.
-
@Lorne-Kates said in I'm getting tired of this npm shit:
I tried the program, but I got a "npm package not found" error.
Serves you right for wanting to left-pad a string, you heathen!