Shopify / Shopify/tapioca

Prepending a module can cause `tapioca dsl` to produce an untyped signature

Open
#2,705 0 comments 0 reactions 1 assignee View on GitHub

@KaanOzkan is already working on this.

Since Aug 25, 2026.

bug
Dominant language
Ruby
Stars
873
Forks
164
Avg merge
4d 27m
Merged PRs (30d)
9

Description

A prepended module can cause Tapioca to not find the signature for a method, leading to it generating an untyped signature. Worse yet, this can cause a difference between how tapioca dsl and tapioca dsl Foo work:

  1. tapioca dsl does an eager load, which can load the Ruby file which prepends the module onto Foo. The RBI will have an untyped signature.
  2. tapioca dsl Foo doesn't eager load, so it might not load the file which has the prepended module. The RBI will have a typed signature.

Cause

This stems from the behaviour of T::Utils.signature_for_method, which looks up a signature for a given owner_id/method_name pair. If a prepended module doesn't have a sig, it'll return nil` (even if the method it overrides does have a sig).

require "sorbet-runtime"

class Foo
  extend T::Sig
  
  sig { returns(String) }
  def foo = "original"
end

p T::Utils.signature_for_instance_method(Foo, :foo) # => the real sig

module M
  def foo = "prepended"
end

Foo.prepend(M)

p T::Utils.signature_for_instance_method(Foo, :foo) # => nil

Potential solutions

Keep searching until we find a sig

#: (UnboundMethod) -> [UnboundMethod, T::Private::Methods::Signature]
def first_signature(method)
  while method
    signature = T::Utils.signature_for_method(method)
    return [method, signature] if signature
    
    method = method.super_method
  end
  
  nil
end

method, sig = first_signature(Foo.instance_method(:foo))
p sig

This might be desirable in this case, but cause weirdness in other cases (e.g. when an method override doesn't have a sig, but its method parameter declaration differs from that of its parent method). Needs investigation.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.