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

First-class JSR support

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

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Tranquilo
Stack tecnológico
typescript
Área
compilers

Línea de trabajo

El issue no menciona inicialmente ningún archivo, prueba ni punto de entrada. Primero aclara el comportamiento previsto de resolución de JSR y las restricciones arquitectónicas; después identifica las áreas del compilador y de resolución de dependencias que necesitarían cambios. El trabajo estaría terminado cuando exista un alcance de implementación acordado y se haya validado que las dependencias JSR de TypeScript pueden entrar en el mismo grafo de compilación y comprobación de tipos.

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

Descripción

JSR packages can publish TypeScript source directly, rather than the usual npm model of shipping transpiled JS alongside .d.ts files.

It feels like that could be a really good fit for scriptc. Given something like:

import { something } from "jsr:@scope/package";

could scriptc resolve the package's TypeScript source and include it in the same compilation/type-checking graph as the application code?

My assumption is that, provided the package only uses constructs supported by scriptc's static tier, this could allow the dependency itself to be compiled to native code rather than requiring the dynamic runtime. It would also make JSR a potentially interesting ecosystem for libraries intentionally written to remain statically compilable.

I'm mainly curious whether this is something you've thought about, and whether there are architectural reasons why resolving JSR/TypeScript dependencies this way wouldn't work.

I realize npm compatibility is probably the more immediately useful target given the size of that ecosystem, but first-class JSR support seems like it could complement that nicely, especially for people interested in building mostly or entirely static scriptc applications.

Lenguaje dominante
TypeScript
Estrellas
5.1k
Forks
130
Merge medio
1 h 13 min
PR fusionados (30 d)
245

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 vercel-labs/scriptc

Todos los issues de vercel-labs/scriptc

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.