assignment to function parameter 'item' no param reassign

• Assignment to property of function parameter no-param-reassign

Last updated: Mar 7, 2024 Reading time · 3 min

# Table of Contents

• Disabling the no-param-reassign ESLint rule for a single line
• Disabling the no-param-reassign ESLint rule for an entire file
• Disabling the no-param-reassign ESLint rule globally

# Assignment to property of function parameter no-param-reassign

The ESLint error "Assignment to property of function parameter 'X' eslint no-param-reassign" occurs when you try to assign a property to a function parameter.

To solve the error, disable the ESLint rule or create a new object based on the parameter to which you can assign properties.

Here is an example of how the error occurs.

The ESLint rule forbids assignment to function parameters because modifying a function's parameters also mutates the arguments object and can lead to confusing behavior.

One way to resolve the issue is to create a new object to which you can assign properties.

We used the spread syntax (...) to unpack the properties of the function parameter into a new object to which we can assign properties.

If you need to unpack an array, use the following syntax instead.

The same approach can be used if you simply need to assign the function parameter to a variable so you can mutate it.

We declared the bar variable using the let keyword and set it to the value of the foo parameter.

We are then able to reassign the bar variable without any issues.

# Disabling the no-param-reassign ESLint rule for a single line

You can use a comment if you want to disable the no-param-reassign ESLint rule for a single line.

Make sure to add the comment directly above the assignment that causes the error.

# Disabling the no-param-reassign ESLint rule for an entire file

You can also use a comment to disable the no-param-reassign ESLint rule for an entire file.

Make sure to add the comment at the top of the file or at least above the function in which you reassign parameters.

The same approach can be used to disable the rule only for a single function.

The first comment disables the no-param-reassign rule and the second comment enables it.

If you try to reassign a parameter after the second comment, you will get an ESLint error.

# Disabling the no-param-reassign ESLint rule globally

If you need to disable the no-param-reassign rule globally, you have to edit your .eslintrc.js file.

If you only want to be able to assign properties to an object parameter, set props to false instead of disabling the rule completely.

The following code is valid after making the change.

If you use a .eslintrc or .eslintrc.json file, make sure to double-quote the properties and values.

If you want to only allow assignment to object parameters, use the following line instead.

Make sure all properties are double-quoted and there are no trailing commas if your config is written in JSON.

# Additional Resources

You can learn more about the related topics by checking out the following tutorials:

• eslint is not recognized as an internal or external command
• Plugin "react" was conflicted between package.json » eslint-config-react-app
• React: Unexpected use of 'X' no-restricted-globals in ESLint
• TypeScript ESLint: Unsafe assignment of an any value [Fix]
• ESLint error Unary operator '++' used no-plusplus [Solved]
• ESLint Prefer default export import/prefer-default-export
• Arrow function should not return assignment. eslint no-return-assign
• TypeError: Cannot redefine property: X in JavaScript [Fixed]
• ESLint: disable multiple rules or a rule for multiple lines
• Expected linebreaks to be 'LF' but found 'CRLF' linebreak-style
• Missing return type on function TypeScript ESLint error

Borislav Hadzhiev

Web Developer

Copyright © 2024 Borislav Hadzhiev

Disallow Reassignment of Function Parameters (no-param-reassign)

Assignment to variables declared as function parameters can be misleading and lead to confusing behavior, as modifying function parameters will also mutate the arguments object. Often, assignment to function parameters is unintended and indicative of a mistake or programmer error.

This rule can be also configured to fail when function parameters are modified. Side effects on parameters can cause counter-intuitive execution flow and make errors difficult to track down.

Rule Details

This rule aims to prevent unintended behavior caused by modification or reassignment of function parameters.

Examples of incorrect code for this rule:

Examples of correct code for this rule:

This rule takes one option, an object, with a boolean property "props" , and arrays "ignorePropertyModificationsFor" and "ignorePropertyModificationsForRegex" . "props" is false by default. If "props" is set to true , this rule warns against the modification of parameter properties unless they're included in "ignorePropertyModificationsFor" or "ignorePropertyModificationsForRegex" , which is an empty array by default.

Examples of correct code for the default { "props": false } option:

Examples of incorrect code for the { "props": true } option:

Examples of correct code for the { "props": true } option with "ignorePropertyModificationsFor" set:

Examples of correct code for the { "props": true } option with "ignorePropertyModificationsForRegex" set:

When Not To Use It

If you want to allow assignment to function parameters, then you can safely disable this rule.

Further Reading

• JavaScript: Don’t Reassign Your Function Arguments

This rule was introduced in ESLint 0.18.0.

• Rule source
• Documentation source

© OpenJS Foundation and other contributors Licensed under the MIT License. https://eslint.org/docs/rules/no-param-reassign

no-param-reassign

Disallow reassigning function parameters

Assignment to variables declared as function parameters can be misleading and lead to confusing behavior, as modifying function parameters will also mutate the arguments object. Often, assignment to function parameters is unintended and indicative of a mistake or programmer error.

This rule can be also configured to fail when function parameters are modified. Side effects on parameters can cause counter-intuitive execution flow and make errors difficult to track down.

Rule Details

This rule aims to prevent unintended behavior caused by modification or reassignment of function parameters.

Examples of incorrect code for this rule:

Examples of correct code for this rule:

This rule takes one option, an object, with a boolean property "props" , and arrays "ignorePropertyModificationsFor" and "ignorePropertyModificationsForRegex" . "props" is false by default. If "props" is set to true , this rule warns against the modification of parameter properties unless they’re included in "ignorePropertyModificationsFor" or "ignorePropertyModificationsForRegex" , which is an empty array by default.

Examples of correct code for the default { "props": false } option:

Examples of incorrect code for the { "props": true } option:

Examples of correct code for the { "props": true } option with "ignorePropertyModificationsFor" set:

Examples of correct code for the { "props": true } option with "ignorePropertyModificationsForRegex" set:

When Not To Use It

If you want to allow assignment to function parameters, then you can safely disable this rule.

This rule was introduced in ESLint v0.18.0.

Further Reading

JavaScript: Don’t Reassign Your Function Arguments

• Rule source
• Tests source

© OpenJS Foundation and other contributors Licensed under the MIT License. https://eslint.org/docs/latest/rules/no-param-reassign

How to avoid no-param-reassign ESLint error when setting a property on a DOM object with JavaScript?

• Post author By John Au-Yeung
• Post date April 28, 2022
• No Comments on How to avoid no-param-reassign ESLint error when setting a property on a DOM object with JavaScript?

Sometimes, we want to avoid no-param-reassign ESLint error when setting a property on a DOM object with JavaScript.

In thiks article, we’ll look at how to avoid no-param-reassign ESLint error when setting a property on a DOM object with JavaScript.

To avoid no-param-reassign ESLint error when setting a property on a DOM object with JavaScript, we can assign the parameter to a variable.

For instance, we write

to create the f function.

In it, we assign el to the theElement variable.

And then we add the theElement.expand property to it.

Related Posts

In a DOM node object, we see the tagName and nodeName property when we inspect…

There're a few ways to add properties to an object in JavaScript. One way is…

Sometimes, we may want to remove a CSS property from an HTML element using JavaScript.…

By John Au-Yeung

Web developer specializing in React, Vue, and front end development.

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Save my name, email, and website in this browser for the next time I comment.

no-param-reassign

Disallow reassigning function parameters

对作为函数参数声明的变量进行赋值可能会产生误导并导致混乱的行为，因为修改函数参数也会改变 arguments 对象。通常情况下，对函数参数的赋值是无意的，表明了一个错误或程序员的错误。

这条规则也可以被配置为在修改函数参数时失败。参数的副作用会导致反直觉的执行流程，使错误难以追踪。

这条规则的目的是防止因修改或重新分配函数参数而引起的非预期行为。

使用此规则的 错误 示例：

使用此规则的 正确 示例：

这个规则有一个选项，是一个对象，有一个布尔属性 "props" 和数组 "ignorePropertyModificationsFor" 和 "ignorePropertyModificationsForRegex" 。 "props" 默认为 false 。如果 "props" 设置为 true ，本规则警告不要修改参数属性，除非它们被包含在 "ignorePropertyModificationsFor" 或 "ignorePropertyModificationsForRegex" 中，默认为空数组。

使用默认的 { "props": false } 选项的 正确 示例：

使用 { "props": true } 选项的 错误 示例：

设置了 "ignorePropertyModificationsFor" 的 { "props": true } 选项的**正确的代码示例：

设置了 "ignorePropertyModificationsForRegex" 的 { "props": true } 选项的**正确的代码示例：

如果你想允许对函数参数进行赋值，你可以安全地禁用此规则。

This rule was introduced in ESLint v0.18.0.

Further Reading

• Rule source
• Tests source

Disallow Reassignment of Function Parameters (no-param-reassign)

Assignment to variables declared as function parameters can be misleading and lead to confusing behavior, as modifying function parameters will also mutate the arguments object. Often, assignment to function parameters is unintended and indicative of a mistake or programmer error.

This rule can be also configured to fail when function parameters are modified. Side effects on parameters can cause counter-intuitive execution flow and make errors difficult to track down.

Rule Details

This rule aims to prevent unintended behavior caused by modification or reassignment of function parameters.

Examples of incorrect code for this rule:

Examples of correct code for this rule:

This rule takes one option, an object, with a boolean property "props" and an array "ignorePropertyModificationsFor" . "props" is false by default. If "props" is set to true , this rule warns against the modification of parameter properties unless they're included in "ignorePropertyModificationsFor" , which is an empty array by default.

Examples of correct code for the default { "props": false } option:

Examples of incorrect code for the { "props": true } option:

Examples of correct code for the { "props": true } option with "ignorePropertyModificationsFor" set:

When Not To Use It

If you want to allow assignment to function parameters, then you can safely disable this rule.

Further Reading

• JavaScript: Don’t Reassign Your Function Arguments

This rule was introduced in ESLint 0.18.0.

• Rule source
• Documentation source

Disallow Reassignment of Function Parameters (no-param-reassign)

禁止对函数参数再赋值 (no-param-reassign).

Assignment to variables declared as function parameters can be misleading and lead to confusing behavior, as modifying function parameters will also mutate the arguments object. Often, assignment to function parameters is unintended and indicative of a mistake or programmer error.

对函数参数中的变量进行赋值可能会误导读者，导致混乱，也会改变 arguments 对象。通常，对函数参数进行赋值并非有意为之，更多的是程序员的书写错误做成的。

This rule can be also configured to fail when function parameters are modified. Side effects on parameters can cause counter-intuitive execution flow and make errors difficult to track down.

当函数参数被修改时，该规则也可能会失效。由此造成的副作用可能导致不直观的执行流程，使错误难以跟踪。

Rule Details

This rule aims to prevent unintended behavior caused by modification or reassignment of function parameters.

该规则旨在避免出现对函数参数的修改或重新赋值造成的非自主行为。

Examples of incorrect code for this rule:

Examples of correct code for this rule:

This rule takes one option, an object, with a boolean property "props" and an array "ignorePropertyModificationsFor" . "props" is false by default. If "props" is set to true , this rule warns against the modification of parameter properties unless they’re included in "ignorePropertyModificationsFor" , which is an empty array by default.

该规则有一个选项，是个对象，其中有一个 "props" 的布尔属性和一个数组属性 "ignorePropertyModificationsFor" 。 "props" 默认为 false 。如果 "props" 设置为 true ，对参数的任何属性的修改，该规则都将发出警告， 除非在 "ignorePropertyModificationsFor" （默认为空数组） 有该参数。

Examples of correct code for the default { "props": false } option:

默认选项 { "props": false } 的 正确 代码示例：

Examples of incorrect code for the { "props": true } option:

选项 { "props": true } 的 错误 代码示例：

Examples of correct code for the { "props": true } option with "ignorePropertyModificationsFor" set:

选项 { "props": true } 并设置了 "ignorePropertyModificationsFor" 的 正确 代码示例：

When Not To Use It

If you want to allow assignment to function parameters, then you can safely disable this rule.

如果你想允许对函数参数重新赋值，你可以禁用此规则。

Further Reading

• JavaScript: Don’t Reassign Your Function Arguments

This rule was introduced in ESLint 0.18.0.

该规则在 ESLint 0.18.0 中被引入。

• Rule source
• Documentation source

JavaScript: Don’t Reassign Your Function Arguments

UPDATE : The point of this post is to raise awareness that reassigning the value of an argument variable mutates the arguments object. The code example is contrived and exists solely to help illustrate that behavior.

Did you know that a JavaScript function’s named parameter variables are synonyms for the corresponding elements in that function’s Arguments object?

I ran into this while experimenting with a function that was written to take either two or three arguments, providing a default for the first argument if only two are passed.

Strangely, all of the values in the result object are set to "green" . I was expecting to see

But when I set favoriteColor to "green" I was also changing arguments[0] to be "green" . The situation only got worse when I set name = arguments[0] effectively changing arguments[1] to be "green" as well.

I had not realized that named arguments are synonyms for the elements of the Arguments object. I found a good explanation on Rx4AJAX:

The numbered properties of the Arguments Object are synonymous with the local variables that hold the named function parameters. They both reference the same address in the stack. If the function body has code that changes the value of a parameter either via a name reference or the arguments[] array reference, both referenced values will reflect the same value.

Regardless of the language, it is generally not a good idea to reassign the parameter variables inside a function. In JavaScript it turns out to be a really bad idea.

Additional information:

• Check out this jsFiddle to experiment with the code snippet above.
• A comment on this StackOverflow question describes this “magical behavior” of JavaScript.
• JavaScript Garden describes this behavior in its section on the arguments object.

Related Posts

Remix is incredible — if it fits your use case, vercel: a valuable debugging tool, common css pitfalls and how to avoid them, keep up with our latest posts..

We’ll send our latest tips, learnings, and case studies from the Atomic braintrust on a monthly basis.

So the arguments object isn’t a “real” array, so you run into problems when you treat it as such.

Here’s a working example where you turn the arguments object into an array with Array.prototype.slice()

http://jsfiddle.net/wookiehangover/yZPj8/4/

This is a pretty common beginner’s mistake and is covered in most advanced books, such as Javascript Patterns or High Performance Javascript.

Here’s a good resource about how the arguments object works: https://developer.mozilla.org/en/JavaScript/Reference/functions_and_function_scope/arguments

If you slice the Arguments, the get aan array, which is not “live”. This way, you can reassign the arguments without any problems. http://jsfiddle.net/Avorin/yZPj8/6/

When I want to pass a varying number of parameters to a function, I either use a predefined object or an object literal myself to begin with (I presume this example function is simplified).

You can also clutter up the function calls with things like makePerson(null, “Joe”, 18) and test for nulls, too, instead of array lengths.

This is the solution I found, using this. instead of an args array. I’m not sure which solution is better.

http://jsfiddle.net/Q2LMT/

Or simply refer to the arguments by name when changing their values.

This article roughly says:

When you misuse the arguments object, unexpected results happen.

The solution: don’t misuse the arguments object. Leave the param list empty and use your logic to fill out variable names if you need that

This is why I love working with Rails… most Rails functions take hashes as arguments, so you can your real arguments in in any order, and it guarantees code verbosity. Example:

button_to ‘Add to Cart’, line_items_path(:product_id => product), :remote => true

where :remote=>true is the third argument, a hash, and contains all optional parameters you could add (in this case, :method, :disabled, :confirm, and :remote).

var makePerson = function(favoriteColor, name, age) { if (arguments.length < 3) { favoriteColor = "green"; name = arguments[0]; age = arguments[1]; } return { name: name, age: age, favoriteColor: (arguments.length < 3 ? "green" : favoriteColor) }; };

How very Perl-ish of Javascript.

Ignore this blog post’s advice. It is perfectly fine to reassign function arguments in Javascript. If you just follow the convention of putting option arguments at the end of the argument list instead of the beginning, you avoid this problem all together and simplify your code:

var makePerson = function(name, age, favoriteColor) { favoriteColor = favoriteColor || “green”; return { name: name, age: age, favoriteColor: favoriteColor }; };

Who makes the first argument optional? Seriously? There are numerous things wrong with your code.

What a terrible programming language.

Larry Clapp, this isn’t perlish at all. In Perl you do named parameters through local variables. They’re duplicated not ref-copied.

use strict; use warnings;

my $makePerson = sub { my ( $favoriteColor, $name, $age ) = @_;

if ( @_ $name , age => $age , favoriteColor => $favoriteColor }

use Data::Dumper; die Dumper $makePerson->(‘Joe’, 18);

What you’re confusing is Perl’s special array variable `@_` which is used to store references to the parameters from the caller, making them accessible in the callee. So the sub implementation themselves are pass-by-reference, but the assignment itself requires a total copy. Not to say you couldn’t achieve the same effect with Perl if you *really wanted too*, but it requires a ton of non-accidental (contrived) work.

my $makePerson = sub { my ( $favoriteColor, $name, $age ) = ( \$_[0], \$_[1], \$_[2] ); #my ( $favoriteColor, $name, $age ) = @_;

if ( length @_ $$name , age => $$age , favoriteColor => $$favoriteColor }

use Data::Dumper; my $name = ‘Joe’; my $age = 18; die Dumper $makePerson->($name, $age);

How about just using a configuration object?

var person = makePerson({name:”Joe”, age:18})

Inside the function look for the property you want to default.

JavaScript reveals more and more of its awful design. NaN != NaN ?????

the problem isn’t with using arguments , the problem is with your use of it.

Writing the code: function example (x, y, z) { x = 1; y = arguments[0]; z = arguments[1]; }

will make every value 1 because I wasn’t very careful about the order of my actions.

As the article you quoted states, the variables x, y, and z are synonymous with arguments [0], [1], and [2] respectively, so if I called example(3,4) all I would be doing in my function is assigning 3 to x and 4 to y with the function call, then assigning 1 to x, the value of x to y, then the value of y to z. All of my values would be the same (and 1) afterwards.

You do the same thing in your code. You pass in (favoriteColor: Joe, name: 18) and then set the favoriteColor to “green” before taking the value of “green” and pasting it on to the name, then taking the new value of name (also “green”) and pasting it in to the value of age. If you had instead written that code in the reverse order, it would have worked as you had initially expected.

[…] service allows you to react immediately to spikes in website traffic. Just recently our blog had a post go viral on Reddit causing an extreme spike in traffic. Using a live information radiator on our office […]

There are special edge cases like Array.prototype.reduce where assign to accumulator argument passed between iterations is only good practice:

const aggregate = someArray.reduce((acc, item) => { acc[item.prop] = (acc[item.prop] || 0) + 1; }, {} /* this is initial state */);

Choose Parameters or Arguments….but using both is asking for trouble.

If you are using Parameters defined in the Function signature, then you have no need to refer to the arguments information.

If you plan on using arguments, then do not define Parameters.

Mixing the two, is asking for problems and the reason for the overall purpose of this post.

Comments are closed.

Tell Us About Your Project

We’d love to talk with you about your next great software project. Fill out this form and we’ll get back to you within two business days.

Disallow Reassignment of Function Parameters (no-param-reassign)

Assignment to variables declared as function parameters can be misleading and lead to confusing behavior, as modifying function parameters will also mutate the arguments object. Often, assignment to function parameters is unintended and indicative of a mistake or programmer error.

This rule can be also configured to fail when function parameters are modified. Side effects on parameters can cause counter-intuitive execution flow and make errors difficult to track down.

Rule Details

This rule aims to prevent unintended behavior caused by modification or reassignment of function parameters.

Examples of incorrect code for this rule:

Examples of correct code for this rule:

This rule takes one option, an object, with a boolean property "props" and an array "ignorePropertyModificationsFor" . "props" is false by default. If "props" is set to true , this rule warns against the modification of parameter properties unless they’re included in "ignorePropertyModificationsFor" , which is an empty array by default.

Examples of correct code for the default { "props" : false } option:

Examples of incorrect code for the { "props" : true } option:

Examples of correct code for the { "props" : true } option with "ignorePropertyModificationsFor" set:

When Not To Use It

If you want to allow assignment to function parameters, then you can safely disable this rule.

Further Reading

• JavaScript: Don’t Reassign Your Function Arguments

This rule was introduced in ESLint 0.18.0.

• Rule source
• Documentation source

I maginative T hinking .ca

A developers blog

What the Heck is the deal with no-param-reassign

Hey Brad I’m getting a linter error no-param-reassign what is up with that?

The thing to remember about ECMAScript is that it passes by reference.

So when you pass a variable into a function you are not passing the variable value but a reference to the location in memory where the value is located.

When a variable holds a primitive (Number or String) and you re-assign its value your pointing it to a new memory location.

When you modify a variable which holds a primitive value you are changing the memory location stored in the variable.

When you assign the value of one variable to another you are assigning to the second variable the value of the memory location that the first variable is pointing to.

Modifying the second variable will change the memory location the variable points to without affecting the first variable.

But with Objects or Arrays the variable points to a memory location which it self holds references to other memory locations. Often its the child memory locations you end up modifying and not the reference to the object. This is where you can start getting into trouble because you end up changing the value of the callers variable.

Notice here that x and u point to the same object reference. Thus if we modify one of x's properties it means we will also be modifying u's property.

When dealing with Arrays or Objects you need to remember ECMAScript passes by reference .

What this means when it comes to functions is that when you pass a value into a function which you stored in a variable the function invocation will copy the reference address of your object into a parameter variable to be used by the function. If the value is an object or an array and you modify that parameter you will be modifying the callers variable.

In the above both u and x will point to the same object and both will have the newProp property since the parameter user was pointing to the same memory location as u .

How to Make a Function immutable

The first thought when people see the no-param-reassign error is to copy the parameter value into a locally scoped variable.

This does not work as we discussed above; both user and userP will be pointing to the same memory location. It will 100% remove the no-param-reassign error but you will still be mutating the callers variable.

How do we ensure we are not modifying the origin value? We need to clone the object.

Above user and userP will point to two different memory locations. The user variable will point to a different memory location which has an object in it and that object will have properties which point to the same memory location as the properties on the object referenced by userP .

In ES2018 they add the Spread operator for Object Literals so instead of using Object.assign() you can perform shallow copies with const user = {...userP};

Because we now have a completely different object we can add properties to it and update the values in existing properties (we'll update the properties attached to our object to point to different memory locations) without affecting the callers object.

The thing to keep in mind here is that we just did what is known as a shallow copy. A shallow copy just copies the values from the properties on the parent object and does not copy values of nested objects.

If for example we had:

The variables u and x will point to different memory locations however u.obj and x.obj will point to the same location. We can reassign x.obj to a new value (change the memory location it points to) without affecting u , however; attaching new properties to x.obj or changing x.obj.hello will affect both u and x .

In cases where the object in question has nested object and you need to modify the nested objects you need to perform a deep clone which will generate new object in memory for the entire object hierarchy. In our case that would mean we would get different objects for both u and u.obj assigned to x and x.obj respectively. Just keep in mind that deep clones have a higher performance hit then shallow clones as one might expect so best to only do deep clones if you really need to otherwise use shallow clones if you can get away with it.

So that is what the deal is with the no-param-reassign linter error. It warns you that your function might cause unexpected side effects in the callers code because you could be modifying a shared memory location due to ECMAScript's pass by reference design.

Until next time think imaginatively and design creatively

If you liked this post Share it.

• Click to share on LinkedIn (Opens in new window)
• Click to share on Facebook (Opens in new window)
• Click to share on Twitter (Opens in new window)
• Click to share on Google+ (Opens in new window)
• Click to share on Pinterest (Opens in new window)
• Click to share on Tumblr (Opens in new window)
• Click to email this to a friend (Opens in new window)

My interest in computer programming started back in high school and Software Development has remained a hobby of mine ever since. I graduated as a Computer Engineering Technologist and have been working as a Software Developer for many years. I believe that software is crafted; understanding that how it is done is as important as getting it done. I enjoy the aesthetics in crafting elegant solutions to complex problems and revel in the knowledge that my code is maintainable and thus, will have longevity. I hold the designation Certified Technician (C.Tech.) with the Ontario Association of Computer Engineering Technicians and Technologists (OACETT), have been certified as a Professional Scrum Master level 1 (PSM I) and as a Professional Scrum Developer level 1 (PSD I) by Scrum.org as well as designated as an Officially Certified Qt Developer by the Qt Company. For more on my story check out the about page here

Feel free to write a reply or comment. Cancel reply

Search code, repositories, users, issues, pull requests...

Provide feedback.

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly.

To see all available qualifiers, see our documentation .

• Notifications

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement . We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Do we want to recommend the no-param-reassign eslint rule in the docs? #521

phryneas commented Apr 24, 2020

markerikson commented Apr 24, 2020

Sorry, something went wrong.

elramus commented May 6, 2020

Markerikson commented may 6, 2020.

• 👍 11 reactions

phryneas commented May 6, 2020

• 😄 1 reaction

StuartMorris0 commented Jun 9, 2020

Phryneas commented jun 9, 2020.

• 👍 34 reactions
• ❤️ 4 reactions
• 🚀 7 reactions

StuartMorris0 commented Jun 9, 2020 • edited

• 👍 20 reactions

markerikson commented Jun 9, 2020

Stuartmorris0 commented jun 10, 2020.

• 👍 2 reactions

markerikson commented Jun 10, 2020

BenjiTheC commented Nov 15, 2020

• 👍 4 reactions

phryneas commented Nov 15, 2020 • edited

ackalhan commented Dec 30, 2020 • edited

• 😕 2 reactions
• ❤️ 5 reactions

markerikson commented Mar 23, 2021

• 👍 42 reactions
• 🎉 8 reactions
• ❤️ 13 reactions
• 🚀 9 reactions
• 👀 7 reactions

stevedeighton commented Aug 19, 2022

Luk-z commented Oct 13, 2022 • edited

MikelArnaiz commented Dec 22, 2022

• 👍 3 reactions

No branches or pull requests

404 Not found