smart-rb/smart_container

SmartCore::Container is a Ruby library that provides a thread-safe dependency injection container with support for namespaces, memoization, and dependency observation. It allows developers to define and resolve dependencies using a DSL, ensuring thread safety through a ReadWriteLock-based registry. The system includes features for container composition, state freezing, and mixin integration, facilitating modular and maintainable application architecture.

This release adds a new Definition DSL (lib/smart\_core/container/definition\_dsl) that allows users to define container dependencies using \namespace\, \register\, \compose\, and \freeze\_state!\ methods, which are stored in thread-safe command sets protected by \ReadWriteLock\. It introduces memoization support for dependencies via \MemoizedDependency\ entities and a \memoize:\ flag in the \register\ DSL method, defaulting to false. The container now features a \DependencyWatcher\ for observing changes to specific dependency paths and a \Host\ mechanism to properly propagate notifications for nested namespace changes. Additionally, the \Registry\ is now thread-safe, and the \Mixin\ module provides a convenient way to include container functionality in other classes with its own access lock.

_lib/smart\core/container · high confidence

The development console (bin/console) has been updated to require the SmartCore::Container library instead of the previous Siege dependency. This change ensures that the interactive Ruby environment starts with the SmartCore container available for immediate use, facilitating easier debugging and interaction with the containerized components.

bin · high confidence

The container implementation has been significantly refactored to improve concurrency and code organization. It now uses a ReadWriteLock for thread-safe access to the registry, replacing previous locking mechanisms to reduce memory allocation and contention during reads and writes. The class has been expanded from a simple definition to a full-featured container with support for dependency resolution, memoization, namespaces, and host container paths. Internally, the logic has been split into dedicated modules (Registry, DependencyResolver, DependencyWatcher, Host, etc.) to enhance maintainability and allow for more granular control over dependency lifecycle and notification.

_lib/smart\core · high confidence

Added feature tests for SmartCore::Container capabilities; Enable branch and line coverage reporting in specs; Removed SmartCore::Container version test.

The gem now depends on smart\_engine version 0.17, replacing the previous smart-container dependency structure. Development tooling has been updated to support Ruby 2.5+ (down from 2.7), with bundler bumped to \~\> 2.3, rspec to \~\> 3.11, armitage-rubocop to \~\> 1.36, simplecov to \~\> 0.21, and pry to \~\> 0.14. The gem name was also changed from smart-container to smart\_container.

(dependencies) · high confidence

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

• CAI 55 → 60 (+4.8)
• Rubric changed (rubric-2026.08.17 → rubric-2026.09.15) — scores are not directly comparable.

• Code Health 100 → 98 (-1.6)
• Architecture 100 → 100 (+0.0)
• Maturity 43 → 46 (+3.1)
• Readiness 36 → 46 (+10.4)
• Security 100 → 95 (-5.2)

• Coverage not included — suite not readable by the collector
• Dependency hygiene not measured — no supported dependency manifest was read
• No exposed public API
• Test reliability not included
• The container class creation example registers dependencies with memoize: true but the default behavior (memoize: false) is never stated or shown in the visible text. (README.md)
• The runtime-level namespace and dependency registration section describes fetching any type via #fetch but does not explain how to register a new type at runtime. (README.md)
• single-maintainer — knowledge-concentration (bus factor) risk

• Ambiguous duplication: resolve and fetch appear to perform the same core operation (retrieving a dependency by path). In dependency injection contexts, 'resolve' typically implies instantiation or graph traversal, while 'fetch' might imply a simple lookup, but without distinct behavioral documentation, they are confusingly similar public entry points.
• Documentation: no architecture or design documentation (README.md)
• High CVE: [GHSA redacted] (Gemfile.lock)
• High CVE: [GHSA redacted] (Gemfile.lock)
• High CVE: [GHSA redacted] (Gemfile.lock)
• Inconsistent naming for observer management: Container uses observe/unobserve/clear_observers, while the internal DependencyWatcher uses watch/unwatch/clear_listeners. The verbs (observe vs watch) and the noun for the callback (observer vs listener) are inconsistent.
• Inconsistent naming for registration operations: The Container class uses register and namespace as verbs, while the underlying Registry class uses register_dependency and register_namespace. This creates a split in intent expression between the facade (Container) and the internal storage (Registry).
• Medium CVE: [GHSA redacted] (Gemfile.lock)
• Outdated: armitage-rubocop
• Outdated: pry
• Outdated: rake
• Outdated: rspec
• State management inconsistency: Container exposes freeze!, frozen?, and reload!, while Registry only exposes freeze! and frozen?. The reload! capability is missing from Registry, suggesting an incomplete abstraction where the container manages state that the registry should also reflect or expose.
• TodoComment (lib/smart_core/container.rb)
• TodoComment (lib/smart_core/container.rb)
• TodoComment (lib/smart_core/container/dependency_watcher.rb)
• TodoComment (lib/smart_core/container/dependency_watcher.rb)
• TodoComment (lib/smart_core/container/dependency_watcher.rb)
• TodoComment (lib/smart_core/container/dependency_watcher.rb)

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

smart-rb/smart_container was measured the same way every project in this corpus was: the same rubric, at a pinned commit, with the result published in full. Point a surveyor at a repository you know and see whether you agree with it.