respondo 2.1.0 → 2.1.2

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: fb5118a5648863ec54d68805d897485f40da5b81b9b628b9b9a08d6ee2f735d7
-  data.tar.gz: 4282b491b0bd587ba668e7accaf19f6dfb879cc61261d64d744de69c803ae8a0
+  metadata.gz: c72fa46b09dc6370fd885748d78c0a4cc878738fb994d43609edab1af1bee637
+  data.tar.gz: 47a068b005b488305b4bf30a096a38446015643a6650a5c71e7042fe5d49927d
 SHA512:
-  metadata.gz: 4ae4daae47ef9c2c66388fc6d8f3a915b66439208fafa25b7046234813229704de0e53863921f2b4e2100817218b2a315ef40a564c5f672a9848194e55814906
-  data.tar.gz: 86a9ecb6864c1bba75dc4d47941bd0f80c837f4dbc72ed424526e1dad3f05ead92b738a417a239f3fb160e7043fc465418fe6670948be147399ea90ee3ce85d8
+  metadata.gz: ed33945bff899f32f5f599bfeac0ed90906acafe2ddaa0ef8f19f8a1c24699839b9df78bcb033174e79bea720161bd3aa1a5841353193463ab69bbf329b2a9f0
+  data.tar.gz: ff5b519754b9ec2145feaf1611cd7ad29cfc2291f369781e131e175029025d507ad62fef92b4a6057ea2abf92cf77f3bacf6ae778b0f460f94fc6a810af76ce6

data/CHANGELOG.md

@@ -1,5 +1,173 @@
 # Changelog
 
+## [2.1.2] — Code Quality & Test Coverage
+
+### Fixed
+
+#### `controller_helpers.rb` — `render_success` and `render_error` made private
+Previously `render_success` and `render_error` were public methods, meaning any
+controller could call them directly — bypassing the semantic named helpers
+(`render_ok`, `render_created`, `render_forbidden`, etc.) and undermining the
+gem's design intent.
+
+**Before (public — bypassable):**
+```ruby
+# Any controller could do this, skipping semantic intent entirely
+render_success(data: @user, status: :created)
+render_error(message: "bad", status: :not_found)
+```
+
+**After (private — enforced through named helpers only):**
+```ruby
+# Correct usage — callers must use the named helpers
+render_created(data: @user)
+render_not_found(message: "User not found")
+```
+
+**Why:** The named helpers encode the correct HTTP status code, default
+message, and meta code for each scenario. Allowing direct calls to
+`render_success` / `render_error` lets callers set arbitrary status/code
+combinations that break the consistency guarantee.
+
+**Migration:** Replace any direct `render_success` / `render_error` calls in
+your controllers with the appropriate named helper. All named helpers remain
+public and their signatures are unchanged.
+
+---
+
+#### `response_builder.rb` — replaced `defined?(Time.current)` with `Time.respond_to?(:current)`
+The original guard used Ruby's `defined?` keyword to check for Rails'
+`Time.current`. However, `defined?(Time.current)` always returns `"method"`
+as long as the `Time` constant exists — making the `else` branch permanently
+unreachable even in non-Rails environments.
+
+**Before (broken guard — else branch unreachable):**
+```ruby
+def current_timestamp
+  if defined?(Time.current)   # always truthy — else never runs
+    Time.current.iso8601
+  else
+    Time.now.utc.iso8601      # dead code
+  end
+end
+```
+
+**After (correct guard — both branches reachable):**
+```ruby
+def current_timestamp
+  if Time.respond_to?(:current)   # false outside Rails
+    Time.current.iso8601
+  else
+    Time.now.utc.iso8601           # correctly used in plain Ruby
+  end
+end
+```
+
+**Why:** `respond_to?` correctly returns `false` in plain Ruby environments
+where ActiveSupport is not loaded, allowing the `Time.now.utc` fallback to
+actually execute. Behaviour in Rails is identical since `Time.respond_to?(:current)`
+returns `true` when ActiveSupport is present.
+
+---
+
+#### `install_generator.rb` — blank `api_version` no longer writes empty key to initializer
+Previously, if a user entered a blank api_version at the prompt, the generator
+would write `api_version: ""` into the initializer's `default_meta` block —
+a meaningless empty string that would be sent in every API response.
+
+**Before (wrote empty key):**
+```ruby
+meta = { "api_version" => @cfg[:api_version] }.merge(@cfg[:default_meta])
+# If api_version is "" → writes: api_version: ""
+```
+
+**After (omits blank api_version):**
+```ruby
+meta = @cfg[:default_meta].dup
+meta["api_version"] = @cfg[:api_version] unless @cfg[:api_version].to_s.empty?
+# If api_version is "" → key is cleanly omitted
+# If no extra meta either → writes: config.default_meta = {}
+```
+
+**Why:** An empty `api_version` key adds noise to every response's meta block
+with no value. The generator now omits it cleanly, and the previously
+unreachable `config.default_meta = {}` branch is now correctly written when
+both `api_version` is blank and no extra meta fields were added.
+
+---
+
+### Changed
+
+#### Test coverage improved from 97.92% → 100%
+All previously uncovered branches are now exercised:
+
+| File | Branch previously missed | Fix |
+|------|--------------------------|-----|
+| `controller_helpers.rb` | `extract_errors` — `ActiveModel::Errors`, `Array`, `String`, and unknown-type paths | Added `send(:extract_errors, ...)` specs |
+| `response_builder.rb` | `else` branch of `current_timestamp` (non-Rails fallback) | Fixed guard + added branch specs |
+| `install_generator.rb` | `if meta.empty?` branch in `build_content` | Fixed generator logic + added spec |
+| `serializer.rb` | `serialize_record` — `elsif respond_to?(:to_h)` and `else` (bare record) | Added `serialize_record` branch specs |
+
+---
+
+## [2.1.1] — Bug Fix
+
+### Fixed
+
+#### `render_no_content` — status mismatch corrected
+Previously `render_no_content` was sending `status: :ok` (200) while setting
+`code: 204` in the meta block. This meant the HTTP response status was 200
+but the meta claimed 204 — inconsistent and misleading to clients.
+
+**Before (buggy):**
+```ruby
+def render_no_content(message: "Deleted successfully", meta: {}, pagination: nil)
+  render_success(data: nil, message: message, meta: meta, pagination: pagination, code: 204, status: :ok)
+  #                                                                                          ^^^^^^^^^^
+  #                                                                                          wrong — sends 200
+end
+```
+
+**After (fixed):**
+```ruby
+def render_no_content(message: "Deleted successfully", meta: {}, pagination: nil)
+  render_success(data: nil, message: message, meta: meta, pagination: pagination, code: 204, status: :no_content)
+  #                                                                                          ^^^^^^^^^^^^^^^^^^
+  #                                                                                          correct — sends 204
+end
+```
+
+**Why body is kept:** HTTP spec discourages a body on 204 but does not
+strictly forbid it. Respondo keeps the JSON body so FE clients can display
+the `message` field on delete confirmations. Rails and all major HTTP clients
+(Axios, Fetch, OkHttp) handle this correctly.
+
+**Migration:** No changes needed — method signature is identical. If you were
+relying on the incorrect 200 status in tests, update your assertions to
+expect 204.
+
+### Changed
+
+#### `respondo.gemspec` — corrected `bug_tracker_uri`
+A stray `auditron/` path segment was present in the `bug_tracker_uri` metadata
+field, producing a broken link on RubyGems.
+
+**Before:**
+```ruby
+"bug_tracker_uri" => "#{spec.homepage}/auditron/issues"
+```
+
+**After:**
+```ruby
+"bug_tracker_uri" => "#{spec.homepage}/issues"
+```
+
+#### `response_builder.rb` — removed stale commented-out code
+A dead `build_meta` implementation was left commented out from a previous
+refactor. Removed to keep the file clean and readable.
+
+---
+
 ## [2.1.0] — Interactive Install Generator
 
 ### Added