Skip to content

Latest commit

 

History

History
40 lines (35 loc) · 3.17 KB

File metadata and controls

40 lines (35 loc) · 3.17 KB

MK Framework Guidelines

Commands

  • Install the root bundle: bundle install
  • Run framework tests: bundle exec rake
  • Run framework specs: bundle exec rspec spec
  • Build the gem: bundle exec rake build

Releases

  • Publish releases to RubyGems, not GitHub Releases. Do not create GitHub Releases; Git tags can still mark versions.
  • Run the framework tests and build the gem before publishing it with gem push pkg/mk_framework-VERSION.gem (replace VERSION with the release version).
  • After publishing, verify the version on RubyGems and update the latest release version and its RubyGems link at the top of README.md. Keep the README installation examples and gem filename in sync with the published version.

Design and style

  • Include # frozen_string_literal: true in Ruby files.
  • Generate bracketed symbol arrays such as [:id, :title], not %i[id title].
  • Always put spaces inside nonempty Ruby hash braces, including generated code: { post: model }. Keep empty hashes as {}.
  • Use small Ruby blocks and explicit requires; keep classes in an application module.
  • Configure an absolute root and namespace, then call App.boot! after defining the app.
  • Controllers own data access, authorization, attribute assignment, and explicit multi-record transactions.
  • Return a Sequel model from standard create/update/delete actions: framework dispatch calls save/save/destroy once, then converts it to raw attributes. Show/index results are only materialized.
  • Handlers receive raw hashes and arrays, filter fields, and format responses/statuses; they never query, save, delete, or load associations.
  • Use handler do |r| for response blocks and route do |r| for controllers.
  • Handlers return Hash/Array values; use r.halt for explicit early HTTP responses. Do not call to_json in handlers.
  • Require mk_framework/sequel for automatic action persistence and raw data conversion. Include MK::Persistence only for pagination or explicit transactions; after explicit writes return raw data to avoid a second lifecycle write.
  • Use r.path_params for URL identifiers and r.input for allowlisted typed body/query fields.
  • Scope nested member lookups and writes through the authorized parent.
  • Use Sequel migrations and private test databases. Never create tables during server boot.
  • Use rack/test and Rack::Test::Methods for generated request specs. Test updates with PUT only, without a PATCH/PUT loop, and serialize request bodies with .to_json.
  • Test real PATCH/PUT/DELETE behavior and retained POST compatibility routes.
  • Add meaningful regression tests for changed behavior and propagate child test failures.
  • Use the README and docs for the current API; success/error persistence blocks and register_nested_resource belong to the old prototype and are no longer supported.

Generated request examples

Generate five explicit CRUD examples using plain describe and direct HTTP calls. Import the application namespace in the spec helper so model references are short. Do not generate examples with loops or public_send. Keep only the array/400 invalid-update check inside the PUT example; omit null/blank status matrices.