A few days ago some news about a popular npm package containing malicious code went viral. The whole incident is a reminder that we should think twice before adding another package to our dependencies.
It also reminded me of an unnecessary Vue plugin that I’ve seen pop up a few times. Vue‘s gentle learning curve makes it a popular choice with beginner developers, for whom it is even harder to figure out what to write themselves and what to install.
The offender
The package/plugin that I want to talk about is vue-axios. If you google “vue axios” it’s the first result. And I think that’s the main reason of it's popularity.
imcvampire
/
vue-axios
A small wrapper for integrating axios to Vuejs
vue-axios
A small wrapper for integrating axios to Vuejs
Why
I created this library because, in the past, I needed a simple solution to migrate from vue-resource to axios.
It only binds axios to the vue instance so you don't have to import everytime you use axios.
How to install:
ES6 Module:
npm install --save axios vue-axios
Import libraries in entry file:
// import Vue from 'vue' // in Vue 2
import * as Vue from 'vue' // in Vue 3
import axios from 'axios'
import VueAxios from 'vue-axios'
Usage in Vue 2:
Vue.use(VueAxios, axios)
Usage in Vue 3:
const app = Vue.createApp(...)
app.use(VueAxios, axios)
Script:
Just add 3 scripts in order: vue, axios and vue-axios to your document.
Usage:
in Vue 2
This wrapper bind axios to Vue…
Let’s see what a plugin with 1000+ Github stars and 23,000 weekly downloads does. We can start by reading a description:
Usage:
This wrapper bind axios to Vue or this if you're using single file component.
There's also a code example which makes the use of the plugin even more clear:
Vue.axios.get(api).then((response) => {
console.log(response.data)
})
this.axios.get(api).then((response) => {
console.log(response.data)
})
this.$http.get(api).then((response) => {
console.log(response.data)
})
Basically, this package allows you to import axios once and then use it in every component.
It’s actually quite useful. Not only don't you have to import axios in every component but also you can create an axios instance with a custom config and use it in all of them. However, it’s not really mentioned in the plugin's description, therefore I’m not sure if people installing the plugin are even aware of that.
An alternative
We determined that this plugin can be really useful. So what is the problem? Let's code the same functionality without using the plugin:
import Vue from 'vue'
import axios from "axios";
Vue.prototype.$http = axios;
Vue.prototype.axios = axios;
Let's compare it with the code required to configure the plugin:
import Vue from 'vue'
import axios from 'axios'
import VueAxios from 'vue-axios'
Vue.use(VueAxios, axios)
As we can see it takes the same amount of lines to write the whole functionality ourselves as it takes to configure the plugin.
Let's finish by showing slightly supercharged version of this approach of using axios with Vue:
import Vue from 'vue'
import axios from "axios";
const instance = axios.create({
baseURL: 'https://myapi.com'
});
const instanceUserApi = axios.create({
baseURL: 'https://userapi.com'
});
instanceUserApi.defaults.headers.common["Authorization"] =
"Token" + localStorage.getItem("authToken");
Vue.prototype.$http = instance;
Vue.prototype.$httpUserApi = instanceUserApi;
We can create several axios instances each with a different configuration. Not only the plugin doesn't provide any value but it also is less flexible than our code. Just to make it clear the plugin allows you to create many axios instances by passing an object during configuration.
The difference and the excuse
As described in this Github issue:
the different between Vue.prototype and vue-axios? #18
The plugin makes properties(axios and $http) immutable. Which for some may be an advantage over approach described in the previous paragraph. Nevertheless, I'm quite confident that the significant majority of developers using this plugin doesn't really care about immutability.
Conclusion
Vue-axios plugin does what it's description says. There's no dishonesty or anything malicious here in my opinion. Just some uninformed developers that don't think twice about what they add to their projects.
What do you think about such small plugins/packages?
Do you think that creator of such plugins should disclose the alternative?
Top comments (34)
Unfortunately I feel it might be very popular to beginners. People who learn from videos, blogs first before official docs.
I've had a different but similar scenario with VeeValidate. Unlike vue-axios, it offers so much more. It has so many useful features. But it comes at a price, its bundle size, which is larger than vue itself.
A plugin like VeeValidate though can be avoided/skipped in favour of just regular expressions and v-bind tricks.
You can also use vuelidate which is good enough for most cases an smaller than veevalidate...
I started with it. But it doesn't play fair with typescript. Issues filed on the repo and PRs submitted as solutions but the repo owners also didn't meet devs halfway. On top of that, the site that introduced me to VeeValidate had a section after its intro that rants about the latter. Here just scroll to the last section.
Read the rant, he does have a point but I feel like also TypeScript can be a burden on maintainers that don't know/use/like it. He should have probably accepted the patch after making sure that the contributor was available on maintaining TS support from then on.
Very true. I wonder if anyone cared to fork the project just for typescript intergation 🤔
It's always tricky. Everytime you accept a big patch you're also going to maintain it in the future. If you fork a project like this because of the lack of a "small" feature, you're also going to need to keep it in sync, updating the types definition everytime there's something new.
There's no perfect solution
I use both VeeValidate and Vuelidate on several production apps. I love that Vuelidate is model-based and not DOM-based... But it's significantly harder to use for more complex things. The documentation for anything past the basics is utterly worthless and they keep changing validators so that, apps that worked just fine in the past, now fail validations all over the place if updated because of changed behavior.
Because of this, I've mostly converted back to VeeValidate. I'd prefer to stick with Vuelidate, as its API makes more sense IMO and it's ridiculously simple to add custom validations to... But inconsistencies in functionality and the fact that writing conditional validations can be an utter mess has me saying away from it. I wish there were more good options out there, honestly.
After trying both for my side project. I ended up with just this
A little bit more work but I believe it's worth it
I don't agree entirely but I can understand your frustration.
Lately though I'm thinking more about the cost of open source from all sides. Vuelidate is a perfectly fine library and as you say, its API is nice and users can use it easily. But it has limitations, because it's aimed at simple scenarios that can be mapped on top of it. If you want full control you'll end up looking for alternatives.
This doesn't make VueValidate bad, it just makes it geared to some cases but not all. At the same time as you said you have VeeValidate which is more complicated to use but can scale a little better than Vuelidate. Unfortunately it's also massive in size.
Definitely, or maybe VeeValidate needs to be split up in plugins? Don't know, just an idea.
The issue with custom tailored validation logic (reminds me of the hacks on top of jQuery back in the day :D) is that it doesn't scale as in: it will get complicated quickly, especially if your validation is complex (and mine was, that's why I had to leave Vuelidate for VeeValidate) or if you don't want to start from scratch everytime you start a new app.
I'm not saying your case should use a library, but that a library has its purposes.
Again, there's no perfect solution :D
Or the way how i described it - shamelessly plugging my own article :d
Small details make a difference
André
Don't worry, you should just use
nuxt-plugin-axios, which wrapsvue-plugin-axiosfornuxt;)Excellent subject-choice! As a novice, I've been particularly guilty of this "Plugin First" approach, only to find that wrapping my head around the use of the plugin is often no time-saver compared with the unwrapped lib.
Some great insights here and as far as your questions go, my opinions are:
1) Small plugins/packages can be really useful, and I think this aspect of web development is a carry-over from the jQuery days where you could easily import a script to handle some kind of UI feature without writing your own. It has an appeal in the sense that it is a time saver as well as having some sort of "credibility" as a published open source tool that others have used in their own projects.
However, this leads to relying on plugins being a crutch, and I think that it can hinder developers from improving their skills by leaning on them too much. I know when I first started, I tended to use these scripts a lot, and became frustrated when they didn't do exactly what I needed it to do. This led me to start writing my own solutions and I think that exercise is what helped me improve my own skills.
2) I don't think the onus of offering alternatives should be placed on the plugin developer. Most well-curated plugins have some kind of documentation, and a lot of the times, it has some high-level description of what it does, and perhaps why it was created in the first place. It's often phrased like a sales pitch, but I can understand why. The plugin developer wants people to use their tool; after all, that's why they open sourced it in the first place, right? I think a "buyer beware" policy should be followed by any who want to use these types of tools.
Omg, "jQuery plugins" make my blood boil.
Like:
- here's a vanilla-DOM library
- do you have a version for jQuery?
Or even:
- here's a library of pure functions that don't touch the DOM.
- so modern, so modular! But how do I use it with jQuery?
That's because so many people learned jQuery without learning JS, so they were scared of if. Dark times...
Well, I was so scared of jQuery, I just avoided the clientside all together until it left.
What do you think about this approach?
In my opinion, it's a valid approach. Declaring global variables is generally considered a bad coding practice. However, I feel like if you don't abuse it and you are not working on a really big project it doesn't matter as much.
I think that the advantage of using the prototype approach is that usually, you want to make API calls in relation to the component life cycles and events. So making axios available only by components code ensures that API calls are made only in the right moment(you can still pass axios as an argument to a function or a class). This is a quite broad topic so you can easily argue that what I wrote is not always true. Nevertheless, I hope that you can see some advantages of using the prototype approach.
Thank you for clarification.
I think it's too small and blurry for me to read.
Plugins: as many as you need, but no more than necessary.
Before looking for a plugin, I ask myself:
1) How do you code it yourself?
Learn something!
2) Is it worth the time to learn a fix?
I usually put a time limit, if I'm not getting somewhere in 30 minutes with this problem, move on.
3) Will this plugin fix other problems?
I recently used a date plugin because dates are nasty to work with. Life got better.
4) Does the plugin really save time?
If you spend hours fighting with a plugin, find another solution.
5) How many moving parts does this project have, should we add more?
The more plugins you have, the more likely there is to be a conflict... with code you didn't write.
For the sake of decoupling, I think it’s best to only use this.$http even if mapped to axios.
If ever you need to change the library, you won’t need to change all the components (or have a misnomer).
Even better, create an API module that exports specific methods that represent endpoints which in turn use the axios instance.
Oh wow, I never noticed that before. After reading this post I have removed VueAxios from my project, really I don't need it when I am using "this.axios.get..." everywhere, 2 lines of prototype solved it for me.
Thank you for sharing this info
There's a module for Drupal 7 called jquery_dollar. It contains the usual Drupal boilerplate and boils down to this:
It is (was?) very popular, because people cargo-cult it in and don't understand anything about scope.
There was an app called "Less.app" (I think) that ran on a Mac and watched a directory for changes, and then recompiled the CSS from Less. It did what "Sass watch" does but for Less, and it was totally, utterly and in all ways unnecessary. It sold for 99 cents and was immensely popular, because obvious cargo-cult and shiny Mac reasons.
Every time a new package manager comes along, there's a scramble to re-write everything that's ever been made in a different language, driven mostly I think by people's desire to be able to say they're the maintainer of a project which was already doing quite alright and didn't need a makeover, and hey now it's trailing a version behind and has all-new bugs.
I think wherever you look you'll find these sort of examples. I think you always will. It's not really anyone's failure if they use trivial anti-packages like this, it's just because there's so much to learn and not enough time to question every step you read in most of the tutorials you find online.
While I would typically agree that a plugin for such a use case, the second block of code is much more in line with how I would want the code to look, from a code quality perspective. Dynamically modifying a prototype you dont control in a system that doesnt actively type check or error/warn for overwriting these properties is a lot worse than the flow of having an extension and registering it to the global object.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.