Good First Issues in Crystal

These Python and Java detectors don't have a unit spec under spec/unit_test/detector/ yet, while their neighbours do (see python/sanic_spec.cr and java/armeria_spec.cr for the usual shape): Detector Source What it looks for Detector::Python::Bottle src/detector/detectors/python/bottle.cr from bottle import ... or import bottle in a .py file Detector::Python::Quart src/detector/detectors/python/quart.cr from quart import ..., from quart.<sub> import ... or import quart in a .py file Detector::Python::Robyn src/detector/detectors/python/robyn.cr from robyn or import robyn in a .py file Detector::Java::Javalin src/detector/detectors/java/javalin.cr io.javalin in a .java file Detector::Java::Dropwizard src/detector/detectors/java/dropwizard.cr io.dropwizard in a .java file Detector::Java::Micronaut src/detector/detectors/java/micronaut.cr io.micronaut or micronaut.io in a .java file Detector::Java::Quarkus src/detector/detectors/java/quarkus.cr io.quarkus or quarkus.io i

Most Go detectors have a small unit spec under spec/unit_test/detector/go/ (see echo_spec.cr, gin_spec.cr, chi_spec.cr), but these seven don't have one yet: Detector Source What it looks for Detector::Go::Hertz src/detector/detectors/go/hertz.cr github.com/cloudwego/hertz in go.mod only Detector::Go::Huma src/detector/detectors/go/huma.cr github.com/danielgtaylor/huma in go.mod or a .go file Detector::Go::Gf src/detector/detectors/go/gf.cr github.com/gogf/gf in go.mod or a .go file Detector::Go::Goyave src/detector/detectors/go/goyave.cr goyave.dev/goyave in go.mod only Detector::Go::GoRestful src/detector/detectors/go/go_restful.cr github.com/emicklei/go-restful in go.mod or a .go file Detector::Go::ConnectRpc src/detector/detectors/go/connect_rpc.cr connectrpc.com/connect in go.mod or a .go file Detector::Go::Pocketbase src/detector/detectors/go/pocketbase.cr github.com/pocketbase/pocketbase in go.mod, or pocketbase/tools/router in a .go file What to do Add one

String#scan(regex) { |match| ... } always yields a Regex::MatchData, and MatchData#size counts the whole match plus capture groups. The whole match is element 0, so the size is never below 1: $ crystal eval 'p "abc".match!(/b/).size' 1 src/analyzer/analyzers/typescript/tanstack_router.cr still wraps its scan blocks in if match.size > 0 (and if param_match.size > 0) anyway, so those checks never do anything: $ rg -n 'size > 0' src/analyzer/analyzers/typescript/tanstack_router.cr 108: if match.size > 0 132: if match.size > 0 173: if match.size > 0 380: if match.size > 0 396: if match.size > 0 400: if param_match.size > 0 412: if match.size > 0 415: if param_match.size > 0 434: if match.size > 0 It's the same dead check we already cleaned up in the Express, Restify and Koa analyzers (#2720, #2721, #2722). What to do In src/analyzer/analyzers/typescript/tanstack_router.cr only: Remove each of the nine if …size > 0 gu

The other mini-lexer specs under spec/unit_test/minilexer/ follow a *_lexer_spec.cr pattern that mirrors src/minilexers/*_lexer.cr (or the language lexer name): $ ls spec/unit_test/minilexer/ csharp_lexer_spec.cr golang_spec.cr js_lexer_spec.cr php_lexer_spec.cr scala_lexer_spec.cr $ ls src/minilexers/ csharp_lexer.cr golang.cr js_lexer.cr masked_lexer.cr php_lexer.cr sample.cr scala_lexer.cr Go is the odd one out: the source file is golang.cr (no _lexer suffix — that is fine), but the spec is golang_spec.cr instead of golang_lexer_spec.cr, so it does not sit next to the other *_lexer_spec.cr names alphabetically or by convention. What to do git mv spec/unit_test/minilexer/golang_spec.cr spec/unit_test/minilexer/golang_lexer_spec.cr Do not change the require lines unless a path breaks — the file already does require "../../../src/minilexers/golang", which stays valid after the rename. Do not rename src/minilexers/golang.cr in this issue. Nothing else references the path b

Crystal's standard HTTP server currently supports HTTP/1.1 by default. This is not a major problem for many applications, but HTTP/1.1 is an older protocol and modern web applications can benefit from HTTP/2 features such as multiplexing, header compression, and more efficient connection usage. There is already a native HTTP/2 implementation for Crystal, and HTTP/2 is widely supported by modern browsers, HTTP clients, and web servers. Adding experimental support for this shard could make Kemal more suitable for modern services while keeping HTTP/1.1 as the default. Working example The following is a working example using Kemal (master branch) with http2/server: require "kemal" require "openssl" require "http2/server" get "/" do "this is a http2 test" end Kemal.config.ssl = OpenSSL::SSL::Context::Server.new Kemal.config.ssl.not_nil!.certificate_chain = "localhost.crt" Kemal.config.ssl.not_nil!.private_key = "localhost.key" Kemal.run This was tested on Ubuntu 24.04.4 LTS with Crysta

While working with the Invidious codebase, I have found there is some unused variables and functions that were left there and they don't do anything. For example: invidious/src/invidious/helpers/utils.cr Lines 16 to 21 in 3383a30 def elapsed_text(elapsed) millis = elapsed.total_milliseconds return "#{millis.round(2)}ms" if millis >= 1 "#{(millis * 1000).round(2)}µs" end and invidious/src/invidious/helpers/logger.cr Lines 66 to 72 in 3383a30 private def elapsed_text(elapsed) millis = elapsed.total_milliseconds

Having them as such would make Ameba a one-stop shop for all code-related offences. List of all Crystal compiler warnings (18) https://github.com/search?q=repo%3Acrystal-lang%2Fcrystal+%22.add_warning%22&type=code Refs #600