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

Get rid of externs requirement for pure CLJS builds

Abierto
  • ¿Algo no está bien?
#498 1 comentario 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
42/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
clojure, javascript
Área
build-system, database

Línea de trabajo

Comienza en datascript.query, en getter-fn, e inspecciona los usos de aget en busca de inconsistencias en los nombres de propiedades; después revisa el código relacionado con el build de JS y las indicaciones de README.md sobre externs. Compara los builds de CLJS puro con los builds dirigidos a JavaScript; se considera terminado cuando el build de CLJS puro ya no requiere externs y el build de JS existente sigue funcionando.

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

Descripción

There is a very long open issue that datascript requires externs even for pure CLJS compilation. This should never be neccessary for builds where all code is part of the build. Given that shadow-cljs doesn't add externs by default this creates problems. It even has become part of the entry README.md since I assume this is a common issue.

I had a suspicion what the problem is and used AI to confirm. It did, but I do not know enough about this codebase to know if its suggested fixes would actually work. So, here goes the problem.

The code is running into the Inconsistent Property Names problem. Meaning that some places use foo.e and other use foo["e"]. Or more likely the CLJS variants of (.-e foo) and (aget e "foo") (or unchecked-get or any other string based property access). I can see several uses of aget in the codebase, most notably the getter-fn in datascript.query. Given that the set of property names is known it can just use direct getters and not mix in string lookups.

There is also another situation where code contains forced goog/exportSymbol code that is also never necessary for pure CLJS builds and should only be present for the JS targetted builds, not part of the raw sources the CLJS builds will use. But that is a different unrelated issue. Just leads to a lingering datascript global that is also causing problems in ESM builds.

I'd advise moving all the JS build related bits into their own files and doing that build with externs. That would leave the JS build functioning as is, while likely fixing all the CLJS related build issues.

I have no interest in pursuing this myself any further, but given that AI can most definitely fix this, I thought I would bring it up just in case there is any interest in "fixing" the current situation.

Lenguaje dominante
Clojure
Estrellas
5.8k
Forks
318
Sin PR fusionados en 30 d

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 tonsky/datascript

Todos los issues de tonsky/datascript

Issues similares

Más issues de Clojure

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.