Don't test...not even in production!

boomzilla

Plenty of to go around here:

TypeError: axios.get is not a function (v1.1.0) · Issue #5038 · axios/axios

Describe the bug The new version of axios (v1.1.0) is throwing an error for axios.get: TypeError: axios.get is not a function. Note: This issue was not present in v1.0.0 To Reproduce Include axio v...

1 Apparently these chucklefucks introduced a breaking change in v1.1.0.
2 Lots of people in there are saying that their production sites are down.
3 It looks like if you're using this inside Electron (STOP LAUGHING!) it will update itself:

Can repro. This is causing major issues with an electron app of mine. Axios is used via unpkg versionless inside of the asar and there is no way to notify users to update as all requests to autoupdater are handled through axios... This should be reverted, and such a breaking change should have been communicated well in advance (and NOT distributed under a semver minor change!!)

Or...whatever. I don't know enough about Electron or what unpkg or asar are. But whatever they are, this situation is pretty stupid.

loopback0

Yet another one of those issues where like 4 people will learn the lesson and everyone else will get caught out the next time it happens.

Carnage

@loopback0 said in Don't test...not even in production!:

Yet another one of those issues where like 4 people will learn the lesson and everyone else will get caught out the next time it happens.

You have more faith in people than I do.
This lesson was learned decades ago, and yet the web12.9 idiots recreate it over and over.

Unperverted Vixen

@boomzilla unpkg is just a CDN. The problem isn't Electron-related at all. But when some idiot developers referenced the script on the CDN, they said "always give me the newest version of axios" instead of pinning to a specific one, and now they're getting exactly what they asked for.

With a website you can always fix that by editing the site to add pinning. The Electron "issue" is that you can't force users to download a new version of the desktop app.

boomzilla

@Unperverted-Vixen ahhh...yeah, that makes "sense"...at least as far as understanding what happened there. I understood that's what happened with web sties but having to download from a CDN to run a desktop app is its own

topspin

So what even is this thing?

Axios - Promise based HTTP client for the browser and node.js

Features:

Make XMLHttpRequests from the browser

A http client? Isn't that what a browser is? And isn't XMLHttpRequest a function every browser supports?

Example

// Make a request for a user with a given ID
axios.get('/user?ID=12345')
  .then(function (response) {

TypeError: axios.get is not a function

So the very thing this is supposed to do, the first line in the example, it doesn't do?

I am experiencing this breaking change, my production app is broken and unusable to my clients.
We are also experiencing this issue, and will have to wait for app store review for a fix unless the hosted code can be fixed. Adding to the vote for roll back to 1.0
Confirmed as breaking production applications on my end as well. This is a big miss in testing coverage for a library like this.
Pinning axios back to v0.27.2 (https://unpkg.com/axios@0.27.2/dist/axios.min.js) does resolve the issue if anyone is looking for a temporary solution.

Maybe you should've pinned your dependencies to begin with?

I've tested and confirmed going to version 1.0.0 also works, problem is that will require app store review.

What app store is that? I assume the Google one, as I'm sure on the Apple app store your app can't just be the single line:

<script src="http://cdn.chucklefucks.com/app/the-whole-damn-app.js"></script>

Because then what it the fucking point of requiring app store review if it dynamically downloads a completely different app from the web? And what the fuck happens when you're offline?

Go ahead and tell me I'm , but this shit makes my head spin.

topspin

Also, the developer released a dumb breaking change in a minor version. That's a , but it happens. The real problem are the idiots whose software automatically updates unknown third-party code.

Arantor

So to explain... yes, you can use XMLHttpRequest on the client side but it's a bit ugly (the interfacing for it isn't particularly nice especially if you're just doing standard 'get me a thing, call this function when you're done, call that function if shit happened')

Plus I don't think the native XHR interface comes with JS's idea of standardised Promises.

So having a convenience wrapper is not the worst idea in the universe.

As for the various flavours of issues:

It kinda doesn't matter whether you're pulling in the standalone version from a CDN or you're baking it into your single master file, if you're not version pinning, when the interface changes shit is going to get wild - This. Is. JavaScript.
App store review cases - well, when the geniuses did the last build they probably didn't test the specific networked functionality of it. Or, tested locally on 1.0.x because that's what they had locally, did a build without pinning versions and boom, 1.1 lands in the final broken build which clearly wasn't tested.
Part of this problem is because JavaScript is a fucking bucket of shit. Specifically, there's multiple competing standards for how libraries should present their interfaces to the world. Depending on which one you used, you may not have this problem, or you may have the problem that the exact binding of library to outside world changed.
The idiots can't even agree on which version the blessed one is - is it a) 0.27.2, b) 1.0.0, c) 1.1.0, d) 1.1.1, or e) 1.1.2 - answer, depending on your exact circumstances, "yes".

See, in theory for many users this should actually have been pretty seamless. For some it even would have been.

Gribnit

@boomzilla said in Don't test...not even in production!:

STOP LAUGHING!

Never!

kazitor

@Arantor said in Don't test...not even in production!:

So to explain... yes, you can use XMLHttpRequest on the client side but it's a bit ugly (the interfacing for it isn't particularly nice especially if you're just doing standard 'get me a thing, call this function when you're done, call that function if shit happened')

Plus I don't think the native XHR interface comes with JS's idea of standardised Promises.

So having a convenience wrapper is not the worst idea in the universe.

Isn’t that what fetch is about? Surely an API that’s been supported in everything except IE since about 2015 is better than pulling in an external dependency? Especially when you’re targetting Electron so you know exactly what features are supported?

Even with JS developers’ addiction to the Shiny I’d think they can handle a browser shiny in lieu of an external shiny. But I suppose they have addictions to third-parties too.

inb4 “stop trying to make fetch happen”

Arantor

@kazitor Axios has a nicer interface since it natively turns things back into JSON rather than manually making the dev stringify things.

Axios does also have a few things on the fringes that fetch does, e.g. some management around setting timeouts, it also has convenient bindings if you need to apply actions in a middleware fashion.

Also you can do things that are questionable in terms of HTTP; Axios can have GET requests with a body payload, which fetch doesn't. (As the semantics are undefined, there's no standard way for an endpoint to respect it, or not.)

But I'd suspect most devs don't really care about the fancy things and just go with 'it's basically idiot proof AJAX' in a way fetch requires a few basic hurdles.

Carnage

@Arantor

Gribnit

@Carnage said in Don't test...not even in production!:

@Arantor

The defining moment in the career of a backend developer.

Arantor

@Carnage frontend dev is such a colossal shitshow, I can't even. Yup, I can't even, that's about how much of a shitshow it actually is.

Carnage

@Arantor said in Don't test...not even in production!:

@Carnage frontend dev is such a colossal shitshow, I can't even. Yup, I can't even, that's about how much of a shitshow it actually is.

Yeah... I keep saying we still haven't figured out what tools we even need to do frontend dev, because none of the languages, frameworks or methodologies we currently use work well for anything beyond toy problems.

topspin

@kazitor said in Don't test...not even in production!:

inb4 “stop trying to make fetch happen”

Arantor

@Carnage It's kind of bad enough in the regular app space where we have libraries that at least try to start with a logical model for an application (I'm thinking of things like Qt here)

But the web frontend was never designed for this, it's literally the 'document object model', and somehow we evolved it to the point of running fully fledged applications in it.

What I find most interesting is the approach that Google has ultimately taken: Google Docs etc. mostly ignores the DOM at this point in favour of having everything as a bitmap canvas with UI elements overlaid on it where necessary. It feels very full circle back to how things used to be done in the olden days of single-user environments...

Steve_The_Cynic

I said something about this before. What was it? Oh, yes, this...

@Steve_The_Cynic said in Do not upgrade:

The more I read about this web UI shit, the more I'm glad I don't have to do anything with it. Working half the time inside the FreeBSD kernel, half the time in userland but in close symbiosys with the kernel part of our code, I can sit back and read about e.g. leftpad and just laugh at y'all.

Enjoy.

Zecc

@Arantor said in Don't test...not even in production!:

the web frontend was never designed

Arantor

@Zecc said in Don't test...not even in production!:

@Arantor said in Don't test...not even in production!:

the web frontend was never designed

Well, it was designed, just it was designed for making documents with some formatting and linking them together.

It all went wrong when forms were added.

robo2

@Arantor said in Don't test...not even in production!:

@Zecc said in Don't test...not even in production!:

@Arantor said in Don't test...not even in production!:

the web frontend was never designed

Well, it was designed, just it was designed for making documents with some formatting and linking them together.
It all went wrong when ~~forms were~~javascript was added.

izzion

@Arantor said in Don't test...not even in production!:

It all went wrong when ~~forms were added.~~the Fire Nation attacked.

ATFY

Arantor

@robo2 nope, it started to go wrong before that.

For a format designed for marking up documents for connecting them together, why do you need forms?

topspin

@Arantor go ask Adobe why PDFs can embed forms, scripts, and videos (non of which works outside Acrobat Reader Marvel, so much for portable document format). I don't have the Harry Potter paper required to print videos.

Arantor

@topspin that one is easy, so Adobe can sell more copies of Acrobat. But also that was around the time everyone else started getting PDF tools baked in.

But it doesn’t change that this is where it went wrong - making a document format into something it isn’t.

boomzilla

@Arantor said in Don't test...not even in production!:

For a format designed for marking up documents for connecting them together, why do you need forms?

Because we need forms.

Arantor

@boomzilla https://www.youtube.com/watch?v=PEZWYXPvmS8

LaoC

@topspin said in Don't test...not even in production!:

@Arantor go ask Adobe why PDFs can embed forms, scripts, and videos (non of which works outside Acrobat Reader Marvel, so much for portable document format).

Since Google kicked out Flash Player, how else would you install the required malware on a Windows box, eh? Duh!

stillwater

Fucking die you fucking fucks. Y’all won’t learn the lesson this time either.

Now, those of you who don’t work on front end or webcum, what sort of work do you do? I wanna escape to wherever that place is.

Arantor

@stillwater it's also broken, just differently.

topspin

@stillwater said in Don't test...not even in production!:

Now, those of you who don’t work on front end or webcum, what sort of work do you do? I wanna escape to wherever that place is.

loopback0

@stillwater said in Don't test...not even in production!:

what sort of work do you do? I wanna escape to wherever that place is.

You don't

Carnage

@stillwater said in Don't test...not even in production!:

Fucking die you fucking fucks. Y’all won’t learn the lesson this time either.

Now, those of you who don’t work on front end or webcum, what sort of work do you do? I wanna escape to wherever that place is.

I usually do green field development of new services, mainly backend. It's pretty nice if you manage to not end up with idiots on your team. Which, given that 9/10 of devs should just take up competitive knitting instead is rare.
But this time I might get lucky again.

Arantor

@Carnage Sturgeon's Law underestimates again.

Kamil Podlesak

Just a little practical node...

@kazitor said in Don't test...not even in production!:

@Arantor said in Don't test...not even in production!:

So to explain... yes, you can use XMLHttpRequest on the client side but it's a bit ugly (the interfacing for it isn't particularly nice especially if you're just doing standard 'get me a thing, call this function when you're done, call that function if shit happened')

Plus I don't think the native XHR interface comes with JS's idea of standardised Promises.

So having a convenience wrapper is not the worst idea in the universe.

Isn’t that what fetch is about? Surely an API that’s been supported in everything except IE since about 2015 is better than pulling in an external dependency? Especially when you’re targetting Electron so you know exactly what features are supported?

Even with JS developers’ addiction to the Shiny I’d think they can handle a browser shiny in lieu of an external shiny. But I suppose they have addictions to third-parties too.

There is one reason why it continued to be used even when browser fetch support become standard: it is also available for the node.js, so the same code can be used in both frontend and backend. Which is quite useful, for obvious reasons.

I would, however, recommend using node-fetch library for this purpose. It's way smaller, but it has less amount of screw-ups (there might be a correlation here ).

LaoC

@stillwater said in Don't test...not even in production!:

Fucking die you fucking fucks. Y’all won’t learn the lesson this time either.

Now, those of you who don’t work on front end or webcum, what sort of work do you do? I wanna escape to wherever that place is.

BOFH. It's OK, although given the choice I'd do more dev stuff as long as it's not frontend.

dkf

@Arantor said in Don't test...not even in production!:

@robo2 nope, it started to go wrong before that.

For a format designed for marking up documents for connecting them together, why do you need forms?

So that users can type in something that the server needs to know in order to give you a suitable document. Forms predate HTTP and HTML entirely (but they sucked a lot in gopher and wais).

dkf

@Carnage said in Don't test...not even in production!:

But this time I might get lucky again.

Arantor

@dkf this feels like a problem being solved at the wrong level somehow.

Bulb

@Arantor said in Don't test...not even in production!:

@Carnage It's kind of bad enough in the regular app space where we have libraries that at least try to start with a logical model for an application (I'm thinking of things like Qt here)

But the web frontend was never designed for this, it's literally the 'document object model', and somehow we evolved it to the point of running fully fledged applications in it.

The widget tree in the likes of Qt or Gtk or Athena and the DOM look pretty much alike. The widget tree basically defaults to a flexbox-style layout, which is more appropriate for controls, while DOM defaults to layout mechanisms more appropriate to documents, but flexbox and grid were added to cover the other use-case.

If you look at a react jsx and a gtkbuilder or qt ui xml, they look pretty much the same with slightly different names for things.

Bulb

@Arantor said in Don't test...not even in production!:

It kinda doesn't matter whether you're pulling in the standalone version from a CDN or you're baking it into your single master file, if you're not version pinning, when the interface changes shit is going to get wild - This. Is. JavaScript.

NPM even introduced the lock file for this, and a clean-install command that will install the dependencies exactly as pinned for build to make pinning easy. Alas most front-end devs never heard that their release build should be doing npm clean-install instead of npm install.

dkf

@Arantor I'm one of the "the wrong language was used" persuasion, but anything with significant libraries that go with gross incompatibility between minor versions is going to have problems. Programming languages can't fix stupid... except by driving it away and becoming irrelevant because there aren't enough users at all.

Arantor

@Bulb I’d agree with that if not for the fact that React spends a lot of effort presenting that - because there’s a ton of elements in the DOM that simply don’t make any sense for an application model, and you still have to work around the realities of the DOM in React/Vue/etc.

I get what you’re saying about the tree but in my head this feels almost completely different.

Arantor

@Bulb I’d argue that CI should be the default behaviour rather than the current install-but-also-upgrade.

Bulb

@Arantor said in Don't test...not even in production!:

@Bulb I’d agree with that if not for the fact that React spends a lot of effort presenting that - because there’s a ton of elements in the DOM that simply don’t make any sense for an application model, and you still have to work around the realities of the DOM in React/Vue/etc.

I don't do front-end much, but mostly my experience was that there is usually one div for each vbox/hbox or similar layout element I'd have in gtk or qt, label is also just one element, and then for the more complex widgets like buttons and combo-boxes you can see the elements that compose them, but they are composite widgets in qt and gtk as well. There is occasional extra level to facilitate dynamic binding (like switching views), but in general not much more nodes than gtk would have.

I get what you’re saying about the tree but in my head this feels almost completely different.

More general, so there is a bunch of extra parameters all over the place that you don't really need, but not different.

@Arantor said in Don't test...not even in production!:

@Bulb I’d argue that CI should be the default behaviour rather than the current install-but-also-upgrade.

Yes, it should. The way the install command is overloaded for adding dependencies and also restoring dependencies from the manifest is wrong way for encouraging sane practices.

Arantor

@Bulb I think this may indicate that it’s been too long since I did “application development” and/or that I never went deep enough into it to fully see the similarities. Then again I was always doing weird UI stuff like replacing the taskbar or writing a screen ruler app so…

dkf

@Arantor said in Don't test...not even in production!:

@Bulb I think this may indicate that it’s been too long since I did “application development” and/or that I never went deep enough into it to fully see the similarities. Then again I was always doing weird UI stuff like replacing the taskbar or writing a screen ruler app so…

Most application GUI development is about placing (sometimes vaguely) rectangular things on the screen and arranging for them to do the right thing when the user does something. The placement schemes that work well for that are approximately those found in CSS flexbox and grid arrangements; those are suitable for most UIs. (The other "favourite" is absolute placement, but that's fucking awful once you have either internationalization or users who need larger fonts; anyone suggesting absolute placement should have their head examined.) There are other paradigms possible, but they tend to either be very application specific, or to fail in the marketplace.

Because all GUIs work in about the same way, at least at the basic level, all the toolkits for making them easier to write also work in about the same way. They're all essentially object oriented, with code for drawing a basic set of components provided, and a scheme for routing events to the correct areas and responding to some of those for you (stuff like WM_PAINT). Yes, you could do it all yourself, but it is a pain in the ass. Doing everything on an HTML canvas is pretty much exactly such a pain in the ass (precisely because of the lack of interior message routing) except that at least remembers what the surface was drawn as.

Arantor

@dkf sure, but working with HTML is way less sane than that in practice. Especially if you’re writing accessible stuff, where you make navigation (which is often a weird clusterfuck of tags) only to have a “skip this bunch of tags” button.

I dunno if it’s just my experience but most of the stuff I wrote in the desktop world and most of the stuff I do in the web world really don’t feel like there is the same overlap being described except at the very most abstract level.

I think differently when assembling application UIs in toolkits like React to writing anything that directly interacts with the DOM. Ditto when I’m writing UIs in things that are basically “here’s a canvas, imma refresh it 60 times a second, deal with it and do what you gotta do”.

I dunno. Shit’s wild.

dkf

@Arantor said in Don't test...not even in production!:

working with HTML is way less sane than that in practice

I blame JS and DOM.

Arantor

@dkf I believe that was my original point on some level.