thor's secret...

And this allows him to fly?

Is the lightning the cumulative metaphorical sparks caused by billions of bugs?

And the short haft due to the packages’ short lifespan?

I suppose if it really is NPMjölnir, it also makes sense why it’s so easy to crush the entire application with one hand.

@Root perhaps - but only the mighty ones are able to handle it.

@nitwhiz mighty ones.

Mighty as in mighty dumb...

@IntrusionCM you hurt my feelings. Sadly, there is no package for that :(

@nitwhiz if that hurt your feelings...

Lemme get some salt and honey for a good skin rub to prepare your roasting

@IntrusionCM where you're getting that salt from, the fucken himalaya? It's was 3 hours ago you left.

Try npm install salt.

@nitwhiz i was too productive not waiting for a shitty command to download gigabytes of duplicated content to assure version compatibility.

Oh. And I cooked. Had a nice beer.

All stuff you waste on waiting for that crap tool.

@IntrusionCM nice one.
Did the same, while my project did itself by installing five dependencies (containing wheels you reinvented the fifth time).

What did you cook though?

@nitwhiz I'm not programming at the moment. But the statement about reinvention... Jesus christ.

JavaScript is all about reinvention - since every cry baby can release a new framework because something rubbed him wrong.

And as I said - it's all massively duplicated shit. ;)

And NPM / node makes it even worse.

I made some nice meatballs with baked potatoes and bacon beans.

@IntrusionCM you seem to be actually really mad about that javascript stuff, how come?

Because php doesn't really have a platform for it's one-class bullshit called composer packages it has for stuff nobody needs as the language got everything built in already?

No but seriously - I'd like to have a real discussion about it. Why is the js ecosystem seen as so bad? You got packages for problems you'd have to solve yourself again and again, that's the main reason for all the packages.
Isn't that the goal? Reusable code, energy for new ideas instead of the 15th framework nobody is going to use?

As for every crybaby can release packages, that's totally correct. You have to differ between the fucktards releasing their bullshit into the real world and actually usable packages.

That's acutally nice, going to remeber that, thanks for the inspiration.

@nitwhiz Composer does funnily enough a lot of stuff right.

I actually explained multiple times now what rubs me in a wrong way:

Node handles version breaking by just linking an older library version.

That's why you typically have in an dependency tree several versions of one library.

I'm against this in all cases.

Old software MUST die.

What NPM does is - in a nutshell - allowing old software to be available, granting a very false security net as in: It's okay, shit isn't maintained since 5 years, but still available.

Which is wrong.

In the last decades there were multiple incidents which happened for exactly that reason: """ Suddenly """ someone checked a library, found gazillion of bugs, and since Node hosts older versions which are effected too, you've got not one security leak, but a fuckton.

That's one aspect.

The other aspect is that most devs don't get it why Software must die.

One of the biggest issues in IT is the unwillingness to migrate to new versions.

Leading many times to a clusterfuck of lost money, trust, security, developer & admin time and so on.

Python 2 is a great example.

It is dead. But FAANG companies like Google keep it artifically alive - eg in WebKit and their internal projects, like build systems.

So even in 2020 - when Python was officially dead, Python 2.7 has security issues and most modules for Python 2.7 are insecure since unmaintained, thanks to the Philosophy of not letting Software die Python 2.7 still exists in broken state.

And that's what Node does.

@IntrusionCM that's why we got `npm audit`.

Every system depending on dependencies needs to allow co-existence of multiple versions of the same dependency. Or do you have a better idea than just letting the upmost dependency die?

"Old software must die" is a statement i support. But that doesn't work as long as humans write software. By your definition of how software should work, semver wouldn't make any sense. You'd need a versioning system stating the security-safeness of software, not it's current state in time, and that's just bullshit imo.
Every software has bugs and that'd make every software "old" by your definition. Makes no sense as long as humans develop software.

I see less problems than you think this whole system has in the real world, I'd really like to see some real life examples for js, not python. Python is a joke in itself, nobody uses it in production. But js is actually used and companies seem to be happy with it?

@nitwhiz OK. First. Python is used in productive systems.

Stop being shut in on a programming language.

You wanted a serious discussion, then be serious.

SemVer makes a lot of sense. I said explicitly "unmaintained".

SemVer as a system gives clear guidance about what to expect in a new version. So SemVer itself is a solution - since you know when an API break is happening and don't have fun reading tons of VCS entries to get a basic idea.

To Node: I'm lazy. I'm just gonna quote verdaccio github page.

Source:
https://github.com/verdaccio/...

https://theregister.co.uk/2016/03/...

https://github.com/npm/...

https://github.com/npm/...

@IntrusionCM yeah I am serious. You complain about software being vulnerable and bugged. Semver does not address these issues. Semver addresses (api breaking) changes, nothing more.
Current package managers depend on exactly that. A package depends on api of version 2 and so it'll never update this dependency to version 3+. And that's expected.
But if another dependency depends on version 3, we need to keep version 2 and 3 available.

To solve your issues, there is need for a different versioning system. Because semver doesn't address these issues. If software is unmaintained is not represented in semver. Or am I wrong about that?

I don't know whose questions you answered with your serious discussion.

@nitwhiz nope.

You let old software die.

You do not keep unmaintained versions alive.

And that's where SemVer is important: It gives guidance wether a migration is necessary or not.

If it's unmaintained - migrate.

Do not let software which is unmaintained continue being used.