selene Lua linter

The incorrect_standard_library_use lint checks whether you are using the standard library correctly according to Selene's definitions. It identifies calls to standard library functions that use incorrect arguments or patterns.

Note: It is highly recommended that you do not disable this lint. If you encounter issues with the standard library, you should aim to correct your usage or modify your standard library definition to be accurate rather than turning the lint off.

-- Example of code that might trigger this lint:
for _, shop in pairs(GoldShop, ItemShop, MedicineShop) do

When using ipairs to clone a table, table.clone is not an exact functional match if the table contains non-array keys (mixed tables). ipairs only iterates over the array part of a table, whereas table.clone clones the entire table.

If you use ipairs in a pattern that matches the manual clone lint, you will be notified of this potential discrepancy.

Example of a non-equivalent clone:

local mixedTable = { 1, 2, 3 }
mixedTable.key = "value"

local clone = {}

-- This lints, but is NOT equivalent to table.clone because it misses 'key'
for key, value in ipairs(mixedTable) do
    clone[key] = value
end

local mixedTable = { 1, 2, 3 }
mixedTable.key = "value"

local clone = {}

-- Lints, but is not equivalent, since ipairs only loops over the array part.
for key, value in ipairs(mixedTable) do
    clone[key] = value
end

Wildcards (*) allow you to specify requirements for fields that are not explicitly named in your standard library. This is useful for environments where objects can have arbitrary child properties.

• workspace.*: Any field accessed from workspace that isn't explicitly defined will be treated as a specific struct.
• Successive wildcards like script.*.* allow you to define writability for deeply nested dynamic paths.

# Any field accessed from workspace that doesn't exist must be an Instance struct
workspace.*:
  struct: Instance

# Deeply nested dynamic fields have full writability
script.*.*:
  property: full-write

The duplicate_keys rule has specific limitations on what it detects:

• Supported Keys: It only handles keys that are constant string/number literals or named keys (e.g., { a = true }).
• Array-like Values: It handles array-like values by treating them as implicit integer keys. For example, {"foo"} is treated as { [1] = "foo" }.

The global_usage lint is designed to prevent the use of _G, which represents global mutable state. Using _G is considered harmful because it makes code harder to reason about and less modular. Instead of using _G, you should refactor your code to be more modular.

Key constraints:

• Prohibits use of _G.
• In the Roblox standard library, use of shared is also prohibited.
• You can bypass this for specific names using ignore_pattern (a regex).

-- This will trigger the global_usage lint:
_G.foo = 1

The shadowing rule detects when a variable name is reused in a nested scope, effectively hiding the original variable. This is flagged because it can cause confusion when reading code and makes it difficult to access the original variable without refactoring or renaming.

local x = 1

if foo then
    local x = 1 -- This shadows the outer 'x'
end

The globals field is a dictionary where keys are the global names. The value defines how Selene validates that global. You can define globals as:

• Any: Use any: true to allow any usage (indexing, calling, etc.).
• Functions: Defined by providing args and/or method.
• Properties: Defined using the property key to specify writability.
• Structs: Defined using the struct key to link to a named struct.
• Tables: Implicitly created if a global has its own sub-fields defined.