Module Variables Shared across Different Instances of require()

Resources Community Resources
#1

I was doing a project working on a module and I’ve known for a while that module variables are shared across different instances of require()

The way this behavior works is if you set a local variable within the module to a different value it replicates to all instances running the module. To fix this behavior you can simply do this instead of refactoring your code.

--module code example
local PuddleConsole={}
function PuddleConsole.Initialize()
local Puddle = {Set={},Settings={},Player={}}
return Puddle
end
return PuddleConsole

To require this as normal is illustrated by this example.

local PuddleSys=game.ReplicatedStorage.PuddleSystem
local Puddle=require(PuddleSys).Initialize()

Why would you do this?
You may experience bugs if you require multiple instances of the same module that manipulates variables located outside each function. Doing this ensures they are inside the module function.

The behavior of modules in this regard I’m not sure if it extends to tables. Or if the module required is running in a different local machine (actor).

This is mainly a post about me finding a bug and fixing the bug. This solution may not be for everyone but may assist someone looking for a solution or informative to those who were not aware of this being a factor.

#2

This isn’t a bug, module scripts share this data on purpose.

#3

you can change that behavior using metaTables

#4

It’s definitely not a bug but a feature but I don’t think everyone is aware of the behavior. Fortunately, I have always done my stuff accordance with this, I just forgot why today and found out.

#5

Definitely but as long as the data is small is shouldn’t make a performance difference

#6

Isn’t this technically OOP?
It’s returning a table with their own properties that others script can use on their own.

#7

weird use case, i would just define Set, Settings and Player on the script requiring the module and passing it as an argument at this point.

but yes, indeed you can use a function create state

#8

OP has discovered what object orientation is