Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Lua: allow declaring custom module-loader functions so Require("path.lua") maps to import edges

Abierto
  • ¿Algo no está bien?
#1,617 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
55/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
lua
Área
devtools

Línea de trabajo

No implementation files or tests are named. Start by tracing how standard Lua require calls become import edges and how per-project language configuration is handled, using the cited #906 configuration pattern and #660 dependency-edge fix as context. Add coverage for configured loader functions with string-literal and non-literal arguments; done means literal paths resolve to import edges and non-literals retain the current unresolved-call behavior.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Summary

Feature request: let a project declare which functions act as module loaders, so calls like Require("Script/Foo.lua") become imports edges instead of unresolved calls.

Standard require("mod.name") already works — that is not the issue. The gap is codebases that ship their own loader, which is common in embedded Lua (games, plugin hosts) where the host defines a path-based loader rather than using package.path.

Current behaviour

On an indexed 2,107-file Lua game client:

  • unresolved_refs contains exactly 691 entries named Require, matching the number of Require(...) call sites in the source.
  • The whole index has 2 imports edges, both from a standard require("perf.profiler") in one file.
  • So the file→file dependency layer is empty, even though every path is a plain string literal: Require("Script/Activity/ActivityMgrC.lua").

callers on a module file returns 0, and impact on it cannot see the files that load it.

Proposed

Config key listing loader function names, e.g.

{ "lua": { "loaderFunctions": ["Require", "Include"] } }

When a listed function is called with a string literal, resolve it against the project root (and any configured roots) and emit an imports edge to the target file node; fall back to the current unresolved-call behaviour when the argument is not a literal.

Precedent

  • #660 — PHP include/require(_once) were not mapped to dependency edges; fixed. Same shape of problem, except there the construct is language syntax, so no configuration was needed. For Lua the loader is user-defined, hence the config key.
  • #906 — custom extension → language mapping was accepted as opt-in config, so per-project language config already exists as a pattern.

Notes

Low priority relative to #1616: this one only degrades the dependency layer, and only for projects with a custom loader. Standard require users are unaffected.

Lenguaje dominante
C
Estrellas
73.2k
Forks
4.7k
Merge medio
2 h 13 min
PR fusionados (30 d)
418

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de colbymchenry/codegraph

Todos los issues de colbymchenry/codegraph

Issues similares

Más issues de C

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.