hanami / cli Goto Github PK

View Code? Open in Web Editor NEW

27.0 27.0 27.0 663 KB

Hanami command line

License: MIT License

Ruby 96.11% Shell 0.07% HTML 3.71% JavaScript 0.11%

cli's Introduction

Hanami 🌸

The web, with simplicity.

Version

This branch contains the code for hanami: 2.2

Frameworks

Hanami is a full-stack Ruby web framework. It's made up of smaller, single-purpose libraries.

This repository is for the full-stack framework, which provides the glue that ties all the parts together:

Hanami::Router - Rack compatible HTTP router for Ruby
Hanami::Controller - Full featured, fast and testable actions for Rack
Hanami::Validations - Parameter validations & coercion for actions
Hanami::View - Presentation with a separation between views and templates
Hanami::Assets - Assets management for Ruby

These components are designed to be used independently or together in a Hanami application.

Status

Installation

Hanami supports Ruby (MRI) 3.1+.

gem install hanami

Usage

hanami new bookshelf
cd bookshelf && bundle
bundle exec hanami server # visit http://localhost:2300

Please follow along with the Getting Started guide.

Donations

You can give back to Open Source, by supporting Hanami development via GitHub Sponsors.

Supporters

Contact

Home page: http://hanamirb.org
Community: http://hanamirb.org/community
Guides: https://guides.hanamirb.org
Snippets: https://snippets.hanamirb.org
Mailing List: http://hanamirb.org/mailing-list
API Doc: https://gemdocs.org/gems/hanami/latest
Bugs/Issues: https://github.com/hanami/hanami/issues
Stack Overflow: http://stackoverflow.com/questions/tagged/hanami
Forum: https://discourse.hanamirb.org
Chat: http://chat.hanamirb.org

Community

We strive for an inclusive and helpful community. We have a Code of Conduct to handle controversial cases. In general, we expect you to be nice with other people. Our hope is for a great software and a great Community.

Contributing

Fork it ( https://github.com/hanami/hanami/fork )
Create your feature branch (git checkout -b my-new-feature)
Commit your changes (git commit -am 'Add some feature')
Push to the branch (git push origin my-new-feature)
Create a new Pull Request

In addition to contributing code, you can help to triage issues. This can include reproducing bug reports, or asking for vital information such as version numbers or reproduction instructions. If you would like to start triaging issues, one easy way to get started is to subscribe to hanami on CodeTriage.

Tests

To run all test suite:

$ bundle exec rake

To run all the unit tests:

$ bundle exec rspec spec/unit

To run all the integration tests:

$ bundle exec rspec spec/integration

To run a single test:

$ bundle exec rspec path/to/spec.rb

Development Requirements

Ruby >= 3.1
Bundler
Node.js (MacOS)

Versioning

Hanami uses Semantic Versioning 2.0.0

Copyright

cli's People

Contributors

Stargazers

Watchers

cli's Issues

Alphabetise the gems in the newly generated app

In lib/hanami/cli/generators/gem/app/gemfile.erb, change:

<%= hanami_gem("hanami") %>
<%= hanami_gem("router") %>
<%= hanami_gem("controller") %>
<%= hanami_gem("validations") %>
<%= hanami_gem("view") %>
<%- if generate_assets? -%>
<%= hanami_gem("assets") %>
<%- end -%>

<%= hanami_gem("hanami") %>
<%- if generate_assets? -%>
<%= hanami_gem("assets") %>
<%- end -%>
<%= hanami_gem("controller") %>
<%= hanami_gem("router") %>
<%= hanami_gem("validations") %>
<%= hanami_gem("view") %>

Add `db seed` command

hanami-cli 2.alpha6 does not word because of removed method init_bootable

Current version of hanami-cli-2.0.0.alpha6 does not work

Eg, run command ./bin/hanami db migrate causes the exception

.asdf/installs/ruby/3.0.3/lib/ruby/gems/3.0.0/gems/hanami-cli-2.0.0.alpha6/lib/hanami/cli/commands/db/utils/database.rb:72:in `rom_config': undefined method `init_bootable' for MyApp::Application:Class (NoMethodError)
        from .asdf/installs/ruby/3.0.3/lib/ruby/gems/3.0.0/gems/hanami-cli-2.0.0.alpha6/lib/hanami/cli/commands/db/utils/database.rb:82:in `gateway'
        from .asdf/installs/ruby/3.0.3/lib/ruby/gems/3.0.0/gems/hanami-cli-2.0.0.alpha6/lib/hanami/cli/commands/db/utils/database.rb:91:in `run_migrations'
        from .asdf/installs/ruby/3.0.3/lib/ruby/gems/3.0.0/gems/hanami-cli-2.0.0.alpha6/lib/hanami/cli/commands/monolith/db/migrate.rb:33:in `run_migrations'
        from .asdf/installs/ruby/3.0.3/lib/ruby/gems/3.0.0/gems/hanami-cli-2.0.0.alpha6/lib/hanami/cli/commands/monolith/db/migrate.rb:23:in `block in call'
        from .asdf/installs/ruby/3.0.3/lib/ruby/gems/3.0.0/gems/hanami-cli-2.0.0.alpha6/lib/hanami/cli/commands/application.rb:43:in `measure'
        from .asdf/installs/ruby/3.0.3/lib/ruby/gems/3.0.0/gems/hanami-cli-2.0.0.alpha6/lib/hanami/cli/commands/monolith/db/migrate.rb:19:in `call'
        from .asdf/installs/ruby/3.0.3/lib/ruby/gems/3.0.0/gems/hanami-cli-2.0.0.alpha6/lib/hanami/cli/commands/application.rb:15:in `call'
        from .asdf/installs/ruby/3.0.3/lib/ruby/gems/3.0.0/gems/dry-cli-0.7.0/lib/dry/cli.rb:116:in `perform_registry'
        from .asdf/installs/ruby/3.0.3/lib/ruby/gems/3.0.0/gems/dry-cli-0.7.0/lib/dry/cli.rb:65:in `call'
        from .asdf/installs/ruby/3.0.3/lib/ruby/gems/3.0.0/gems/hanami-cli-2.0.0.alpha6/exe/hanami:10:in `<top (required)>'
        from ./bin/hanami:29:in `load'
        from ./bin/hanami:29:in `<main>'

Either always `force` psql drop or allow `force` as option

Context:

The reason behind it is to improve developer experience, as right now when running a command like hanami db reset it will fail if the user has any other ongoing connection, like a connection to db client(like dbeaver), or a hanami console session.

Couple other possible approaches are:

              # create a dedicated method for force drop
              def force_drop_command
                system(cli_env_vars, "dropdb --force #{escaped_name}")
              end

              # force as option/param
              def drop_command(force=false)
              command_prefix =  force ? "dropdb --force" : "dropdb"
              
                system(cli_env_vars, "#{command_prefix} #{escaped_name}")
              end

Reference:
https://www.postgresql.org/docs/current/sql-dropdatabase.html#id-1.9.3.108.6

PR with proposal:
#81

`hanami new` generates incorrect layout, crashing on helpers call

Background

Version: v2.1.0-rc1

When you try to generate a new app using hanami/cli, application will crash due to the incorrect helper names in the layout .

Steps to reproduce

gem install hanami --pre
hanami new sandbox && cd sandbox
hanami g slice main
hanami g action home.show --slice="Main"
bundle exec hanami server
# visit localhost:2300/main/home/1

Application crashes due to favicon, css and js methods in the layouts/app.html.erb not being found

Action generator appends routes even if exists

When you execute bundle exec hanami generate action books.index several times.
You end up with the same routes in routes.rb
Example :

$ bundle exec hanami generate action books.index
$ bundle exec hanami generate action books.index

## config/routes.rb

module Bookshelf
  class Routes < Hanami::Routes
    get "/books", to: "books.index"
    get "/books", to: "books.index"
  end
end

We should have the root only one time what do you think ?

Update CLI action generators to allow rendering of paired view

Add `db migrate` command

$ bundle exec hanami db migrate # Migrates all databases
$ bundle exec hanami db migrate --app # Migrates app database
$ bundle exec hanami db migrate --slice=billing # Migrates "billing" slice database

Note: this already exists as a command, but it has been disabled for a while. It just needs to be reactivated, and updated for the per-slice behaviour.

`hanami g action` overrides existing action + spec

What I tried to do:

hanami g action accounts.show

What I expected to happen:

It would not override the existing files matching those paths (app/actions/accounts/show.rb / spec/actions/accounts/show_spec.rb)

What actually happened:

It overrode those files without asking.

View part generator

Include specs

`hanami server` not taking into account `activate_control_app` option supported by Puma config

ruby 3.1.2
puma (6.2.2)
hanami (2.0.3)
hanami-cli (2.0.3)
rack (2.2.7)

Following shown is my Puma config file containing my custom changes:

config/puma.rb

# frozen_string_literal: true

max_threads_count = ENV.fetch("HANAMI_MAX_THREADS", 5)
min_threads_count = ENV.fetch("HANAMI_MIN_THREADS") { max_threads_count }
threads min_threads_count, max_threads_count

#port        ENV.fetch("HANAMI_PORT", 2300) 
port        ENV.fetch("HANAMI_PORT", 2400) # Note this change
activate_control_app ENV.fetch("PUMA_CONTROL_APP_URL", "tcp://127.0.01:9294") # Note this change
environment ENV.fetch("HANAMI_ENV", "development")
workers     ENV.fetch("HANAMI_WEB_CONCURRENCY", 2)

on_worker_boot do
  Hanami.shutdown
end

preload_app!

When I start the server using hanami server following are the logs

my_api$ bundle exec hanami server
13:20:22 - INFO - Using Guardfile at /.../my_api/Guardfile.
13:20:22 - INFO - Puma starting on port 2300 in development environment.
13:20:22 - INFO - Guard is now watching at ' /.../my_api/'
[9743] Puma starting in cluster mode...
[9743] * Puma version: 6.2.1 (ruby 3.1.2-p20) ("Speaking of Now")
[9743] *  Min threads: 5
[9743] *  Max threads: 5
[9743] *  Environment: development
[9743] *   Master PID: 9743
[9743] *      Workers: 2
[9743] *     Restarts: (✔) hot (✖) phased
[9743] * Preloading application
[9743] * Listening on http://0.0.0.0:2400
[9743] Use Ctrl-C to stop
[9743] * Starting control server on http://127.0.0.1:9293
[9743] * Starting control server on http://[::1]:9293
[9743] - Worker 0 (PID: 9749) booted in 0.0s, phase: 0
[9743] - Worker 1 (PID: 9750) booted in 0.0s, phase: 0

From above it is clear that port option change is picked up but the activate_control_app option specified is not taken into account which is evident from following in the logs:

[9743] * Starting control server on http://127.0.0.1:9293
[9743] * Starting control server on http://[::1]:9293

Also one more thing I noticed related to port is the following inconsistency:

13:20:22 - INFO - Puma starting on port 2300 in development environment.
....
....
[9743] * Listening on http://0.0.0.0:2400

Coming back to my point: activate_control_app is a supported config option as can be seen at https://github.com/puma/puma/blob/v6.2.2/lib/puma/dsl.rb#L198-L235.

But when I directly start the server using following command

bundle exec puma --control-url tcp://127.0.01:9294 --port=2400

then the options are correctly picked-up.

my_api$ bundle exec puma --control-url tcp://127.0.01:9294 --port=2400 
[13389] Puma starting in cluster mode...
[13389] * Puma version: 6.2.1 (ruby 3.1.2-p20) ("Speaking of Now")
[13389] *  Min threads: 5
[13389] *  Max threads: 5
[13389] *  Environment: development
[13389] *   Master PID: 13389
[13389] *      Workers: 2
[13389] *     Restarts: (✔) hot (✖) phased
[13389] * Preloading application
[13389] * Listening on http://0.0.0.0:2400
[13389] Use Ctrl-C to stop
[13389] * Starting control server on http://127.0.0.1:9294
[13389] - Worker 0 (PID: 13393) booted in 0.0s, phase: 0
[13389] - Worker 1 (PID: 13395) booted in 0.0s, phase: 0

Is this a bug on hanami-cli side or it looks like Puma-side issue related to when options are defined in configuration file?

Thanks.

Cli error on "hanami new" -- cannot load such file -- hanami/router/inspector

Following the steps on the beta annoucement gives me an error

❯ ruby -v
ruby 3.1.2p20 (2022-04-12 revision 4491bb740a) [x86_64-linux]

❯ gem install hanami --pre

❯ hanami new bookshelf    
<internal:/home/cassio/.asdf/installs/ruby/3.1.2/lib/ruby/3.1.0/rubygems/core_ext/kernel_require.rb>:85:in `require': cannot load such file -- hanami/router/inspector (LoadError)
        from <internal:/home/cassio/.asdf/installs/ruby/3.1.2/lib/ruby/3.1.0/rubygems/core_ext/kernel_require.rb>:85:in `require'
        from /home/cassio/.asdf/installs/ruby/3.1.2/lib/ruby/gems/3.1.0/gems/zeitwerk-2.6.0/lib/zeitwerk/kernel.rb:35:in `require'
        from /home/cassio/.asdf/installs/ruby/3.1.2/lib/ruby/gems/3.1.0/gems/hanami-cli-2.0.0.beta1/lib/hanami/cli/commands/app/routes.rb:4:in `<top (required)>'
        from /home/cassio/.asdf/installs/ruby/3.1.2/lib/ruby/gems/3.1.0/gems/hanami-cli-2.0.0.beta1/lib/hanami/cli/commands/app.rb:11:in `require_relative'
        from /home/cassio/.asdf/installs/ruby/3.1.2/lib/ruby/gems/3.1.0/gems/hanami-cli-2.0.0.beta1/lib/hanami/cli/commands/app.rb:11:in `<module:App>'
        from /home/cassio/.asdf/installs/ruby/3.1.2/lib/ruby/gems/3.1.0/gems/hanami-cli-2.0.0.beta1/lib/hanami/cli/commands/app.rb:6:in `<module:Commands>'
        from /home/cassio/.asdf/installs/ruby/3.1.2/lib/ruby/gems/3.1.0/gems/hanami-cli-2.0.0.beta1/lib/hanami/cli/commands/app.rb:5:in `<module:CLI>'
        from /home/cassio/.asdf/installs/ruby/3.1.2/lib/ruby/gems/3.1.0/gems/hanami-cli-2.0.0.beta1/lib/hanami/cli/commands/app.rb:4:in `<module:Hanami>'
        from /home/cassio/.asdf/installs/ruby/3.1.2/lib/ruby/gems/3.1.0/gems/hanami-cli-2.0.0.beta1/lib/hanami/cli/commands/app.rb:3:in `<top (required)>'
        from /home/cassio/.asdf/installs/ruby/3.1.2/lib/ruby/gems/3.1.0/gems/hanami-cli-2.0.0.beta1/lib/hanami/cli/commands.rb:15:in `require_relative'
        from /home/cassio/.asdf/installs/ruby/3.1.2/lib/ruby/gems/3.1.0/gems/hanami-cli-2.0.0.beta1/lib/hanami/cli/commands.rb:15:in `register_commands!'
        from /home/cassio/.asdf/installs/ruby/3.1.2/lib/ruby/gems/3.1.0/gems/hanami-cli-2.0.0.beta1/lib/hanami/cli.rb:14:in `<module:CLI>'
        from /home/cassio/.asdf/installs/ruby/3.1.2/lib/ruby/gems/3.1.0/gems/hanami-cli-2.0.0.beta1/lib/hanami/cli.rb:6:in `<module:Hanami>'
        from /home/cassio/.asdf/installs/ruby/3.1.2/lib/ruby/gems/3.1.0/gems/hanami-cli-2.0.0.beta1/lib/hanami/cli.rb:5:in `<top (required)>'
        from <internal:/home/cassio/.asdf/installs/ruby/3.1.2/lib/ruby/3.1.0/rubygems/core_ext/kernel_require.rb>:85:in `require'
        from <internal:/home/cassio/.asdf/installs/ruby/3.1.2/lib/ruby/3.1.0/rubygems/core_ext/kernel_require.rb>:85:in `require'
        from /home/cassio/.asdf/installs/ruby/3.1.2/lib/ruby/gems/3.1.0/gems/hanami-cli-2.0.0.beta1/exe/hanami:5:in `<top (required)>'
        from /home/cassio/.asdf/installs/ruby/3.1.2/bin/hanami:25:in `load'
        from /home/cassio/.asdf/installs/ruby/3.1.2/bin/hanami:25:in `<main>'

Prevent file overwriting

For our generators, we currently overwrite a path if it already exists. We should fix this so it doesn't happen and show a helpful error message letting them know why.

For some cases (e.g. when we make a parent and a child class), we may want to output (and not overwrite) the parent class but continue on and write the child class.

I'm thinking that we can create Hanami::CLI::Files#create which will raise an error if the path exists and use that everywhere we need to. I guess we won't need an update method, since we use some of the methods on dry-files to update content at a certain place.

# Within Hanami::CLI::Files

      def create(path, *content)
        if exist?(path)
          raise FileAlreadyExistsError.new(path) # this is new
        else
          write(path, *content)
        end
      end

Call `db structure dump` from `db migrate`

Absence of `.gitignore` pollutes application git history

Recently finally had the time to play properly with new version of Hanami and encountered an annoyance related to this quote. I did the usual flow when making a new project and uploading it to Github:

hanami new bookshelf
cd bookshelf
# here I followed the Hanami guide, added and ran specs etc.

git init
git add .
git ci -m "Initial commit"
# then set up origin and push to remote

Given that hanami/cli does not include any git related files e.i .gitignore I ended up accidentally commiting a 1k+ log/test.log file which pollutes the history and is simply annoying.

I imagine a lot of people follow similar steps of simply copy commands from Github and trusting this won't happen. Adding a .gitignore to hanami new command can fix this. I'm can help with a contribution if you think this is something worth adding.

App commands should all accept `-e` option to set HANAMI_ENV

Generate db files in `hanami new`

Include these options will let you tailor the output:

--skip-db to skip DB setup
--database=sqlite to use an sqlite database (the default)
--database=postgres to use a postgres database
--database=mysql to use a mysql database

Style up the 404.html and 500.html static error pages

Include dry-operation gem and generate base operation class in new apps and slices

Add `db drop` command

$ bundle exec hanami db drop # Drops all databases
$ bundle exec hanami db drop --app # Drops app database
$ bundle exec hanami db drop --slice=billing # Drops "billing" slice database

Note: this already exists as a command, but it has been disabled for a while. It just needs to be reactivated, and updated for the per-slice behaviour.

Add warning/confirmation when creating a new project in a folder that already exists

Right now, hanami new creates the files and folder regardless of whether any exist.

Instead of doing that, we should prompt the user to ask if it's OK to add files to their existing folder, or to overwrite an existing file. Or, we could just refuse to create a project in an existing folder, to avoid dealing with overwriting issues.

% mkdir foo
% echo "HELLO_WORLD" > foo/README.md
% touch foo/TEST_FILE
% ls foo/
TEST_FILE
% hanami new foo
% ls foo
Gemfile       Gemfile.lock  Guardfile     README.md     Rakefile      TEST_FILE app           config        config.ru     lib           spec
% cat foo/README.md
# Foo

foo/README.md demonstrates that files are overwritten and TEST_FILE shows that existing files aren't deleted.

This same issue and approach should be taken for generating files within a project, e.g. hanami generator action users.show if the users.show action already exists. We don't want to accidentally overwrite the user's file. That can optionally be handled separately, but we should make an issue for that if it doesn't get resolved with the PR that closes this issue.

Add `generate component` CLI command

Example:

hanami generate component some.deep.nested.my_class

module MyApp
  module Some
    module Deep
      module Nested
        class MyClass
        end
      end
    end
  end
end

Stop generating scripts->assets entry in package.json

We're now finding config/assets.js files directly in our CLI commands (as part of the feature to allow for per-slice asset configs), so we don't need this to be exposed to the user anymore.

Add `db create` command

$ bundle exec hanami db create # Creates all database
$ bundle exec hanami db create --app # Creates app database only
$ bundle exec hanami db create --slice=billing # Creates "billing" slice database

Note: this already exists as a command, but it has been disabled for a while. It just needs to be reactivated, and updated for the per-slice behaviour.

Hanami Assets CLI: get the path of the NPM executable from config

See:

cli/lib/hanami/cli/commands/app/assets/compile.rb

Line 18 in 086a69e

# TODO: Take `executable` from Hanami::Assets::Config
cli/lib/hanami/cli/commands/app/assets/watch.rb

Line 23 in 086a69e

# TODO: Take `executable` from Hanami::Assets::Config

Streamline foreman installation for `hanami dev`

Right now, hanami dev will not work if foreman has not been already installed. We need to make this easy for our users.

Some things we can't do:

Foreman can't be a runtime dep of Hanami, because it will be installed in production as well.
It can't be in the app's Gemfile, because foreman ideally works as a directly executable CLI outside bundle

Options here:

Find an idempotent way to install foreman during the hanami install stage of app generation
Do nothing, but have helpful error messages
Generate a bin/dev that installs foreman as part of its first step, and have hanami dev simply execute that file
...

Rationalize all db command output text

Right now it all feels a bit noisy as well as inconsistent. Maybe pare it back a little and keep it simple. Perhaps avoid using the measure block for most of these, since the timing doesn't feel that important, and measure's handling of failures results in confusing back-to-front text ordering (i.e. the specific error messages first, and then the summary of the command that failed underneath it).

`hanami generate action` does not generate views and templates

By the look of #33 it seems that the generation of views and templates was dropped for reasons unclear. I couldn't find any open tasks/issues for it.

If the intention is to add them back at some point I would be glad to give it a shot.

[2.0.0alpha2] cannot load such file -- hanami/version

I'm upgrading a rails app to ruby 3.0, I had an issue with stable versions of hanami-cli so I tried to upgrade to the 2.0.0alpha2, I get this:

/bundle/vendor/ruby/3.0.0/gems/hanami-cli-2.0.0.alpha2/lib/hanami/cli/generators/context.rb:3:in `require': cannot load such file -- hanami/version (LoadError)
	from /bundle/vendor/ruby/3.0.0/gems/hanami-cli-2.0.0.alpha2/lib/hanami/cli/generators/context.rb:3:in `<top (required)>'
	from /bundle/vendor/ruby/3.0.0/gems/hanami-cli-2.0.0.alpha2/lib/hanami/cli/generators/monolith/slice_context.rb:3:in `require_relative'
	from /bundle/vendor/ruby/3.0.0/gems/hanami-cli-2.0.0.alpha2/lib/hanami/cli/generators/monolith/slice_context.rb:3:in `<top (required)>'
	from /bundle/vendor/ruby/3.0.0/gems/hanami-cli-2.0.0.alpha2/lib/hanami/cli/generators/monolith/slice.rb:5:in `require'
	from /bundle/vendor/ruby/3.0.0/gems/hanami-cli-2.0.0.alpha2/lib/hanami/cli/generators/monolith/slice.rb:5:in `<top (required)>'
	from /bundle/vendor/ruby/3.0.0/gems/hanami-cli-2.0.0.alpha2/lib/hanami/cli/commands/monolith/generate/slice.rb:4:in `require'
	from /bundle/vendor/ruby/3.0.0/gems/hanami-cli-2.0.0.alpha2/lib/hanami/cli/commands/monolith/generate/slice.rb:4:in `<top (required)>'
	from /bundle/vendor/ruby/3.0.0/gems/hanami-cli-2.0.0.alpha2/lib/hanami/cli/commands/monolith/generate.rb:8:in `require_relative'
	from /bundle/vendor/ruby/3.0.0/gems/hanami-cli-2.0.0.alpha2/lib/hanami/cli/commands/monolith/generate.rb:8:in `<module:Generate>'
	from /bundle/vendor/ruby/3.0.0/gems/hanami-cli-2.0.0.alpha2/lib/hanami/cli/commands/monolith/generate.rb:7:in `<module:Monolith>'
	from /bundle/vendor/ruby/3.0.0/gems/hanami-cli-2.0.0.alpha2/lib/hanami/cli/commands/monolith/generate.rb:6:in `<module:Commands>'
	from /bundle/vendor/ruby/3.0.0/gems/hanami-cli-2.0.0.alpha2/lib/hanami/cli/commands/monolith/generate.rb:5:in `<module:CLI>'
	from /bundle/vendor/ruby/3.0.0/gems/hanami-cli-2.0.0.alpha2/lib/hanami/cli/commands/monolith/generate.rb:4:in `<module:Hanami>'
	from /bundle/vendor/ruby/3.0.0/gems/hanami-cli-2.0.0.alpha2/lib/hanami/cli/commands/monolith/generate.rb:3:in `<top (required)>'
	from /bundle/vendor/ruby/3.0.0/gems/hanami-cli-2.0.0.alpha2/lib/hanami/cli/commands/monolith.rb:11:in `require_relative'
	from /bundle/vendor/ruby/3.0.0/gems/hanami-cli-2.0.0.alpha2/lib/hanami/cli/commands/monolith.rb:11:in `<module:Monolith>'
	from /bundle/vendor/ruby/3.0.0/gems/hanami-cli-2.0.0.alpha2/lib/hanami/cli/commands/monolith.rb:6:in `<module:Commands>'
	from /bundle/vendor/ruby/3.0.0/gems/hanami-cli-2.0.0.alpha2/lib/hanami/cli/commands/monolith.rb:5:in `<module:CLI>'
	from /bundle/vendor/ruby/3.0.0/gems/hanami-cli-2.0.0.alpha2/lib/hanami/cli/commands/monolith.rb:4:in `<module:Hanami>'
	from /bundle/vendor/ruby/3.0.0/gems/hanami-cli-2.0.0.alpha2/lib/hanami/cli/commands/monolith.rb:3:in `<top (required)>'
	from /bundle/vendor/ruby/3.0.0/gems/hanami-cli-2.0.0.alpha2/lib/hanami/cli/commands.rb:16:in `require_relative'
	from /bundle/vendor/ruby/3.0.0/gems/hanami-cli-2.0.0.alpha2/lib/hanami/cli/commands.rb:16:in `register_commands!'
	from /bundle/vendor/ruby/3.0.0/gems/hanami-cli-2.0.0.alpha2/lib/hanami/cli.rb:14:in `<module:CLI>'
	from /bundle/vendor/ruby/3.0.0/gems/hanami-cli-2.0.0.alpha2/lib/hanami/cli.rb:6:in `<module:Hanami>'
	from /bundle/vendor/ruby/3.0.0/gems/hanami-cli-2.0.0.alpha2/lib/hanami/cli.rb:5:in `<top (required)>'

Add MySQL support for `db` commands

Add `db rollback` command

$ bundle exec hanami db rollback # Rolls back app database
$ bundle exec hanami db rollback 3 # Rolls back app database
$ bundle exec hanami db rollback --app # Rolls back app database
$ bundle exec hanami db rollback 3 --app # Rolls back app database
$ bundle exec hanami db rollback --slice=billing # Rolls back "billing" slice database
$ bundle exec hanami db rollback 2 --slice=billing # Rolls back "billing" slice database

Note: this already exists as a command, but it has been disabled for a while. It just needs to be reactivated, and updated for the per-slice behaviour.

No warning for `hanami new` when the directory already exists

I ran hanami new blog, but didn't realize the current working directory already had a blog/ directory, where I had previously generated a Rails application. The generator happily merged Hanami files into the Rails codebase. It would be great if the hanami new command would abort if the target directory already exists 🙂

What happened to General purpose Command Line Interface framework?

Hi,

I've got hanami-cli 0.3.1 as dependency in a project. It breaks on ruby 3.0 and was looking for a new version. But the new alpha versions seem to have a completely different API.

The link in the 0.3.1 gemfile points to this repository but I cannot find the old code anywhere. It looks like this one is very specific to the hanami framework instead? Does "General purpose Command Line Interface framework" still exists under a new name?

Is `SPEC_ROOT` configured in `spec_helper.rb` used?

I noticed these two lines at the top of the spec_helper.rb generated by hanami new:

require "pathname"
SPEC_ROOT = Pathname(__dir__).realpath.freeze

Are these used by Hanami? It's just something that I haven't seen in other RSpec setups, and was wondering if it can be skipped for new Hanami apps, to keep the code minimalistic.

Add `db structure load` command

$ bundle exec hanami db structure load # Loads the structure for all databases
$ bundle exec hanami db structure load --app # Loads the structure for the app database
$ bundle exec hanami db structure load --slice=billing # Loads the structure for the "billing" slice database

Generate migrations with `generate migration`

For implementation, see the db create_migration command that I removed in #178. We can probably reuse a lot of its code. (Although we shouldn't feel beholden to it; if we can see a better approach, let's feel free to do that!)

hanami db version fails on unapplied migration

Hi there, I'm currently taking a stab at implementing something like rails' db:abort_if_pending_migrations which is quite useful in certain scenarios. While doing so I spotted some weird behaviour which I will try to fix, but thought I open a separate GH issue for documentation purposes.

Whenever a new migration is created the command hanami db version fails. After applying the migration the command works again.

hanami-timetracker on  main [!?] is 📦 v1.0.0 via ⬢ v16.14.2 via 💎 v3.1.2 on 🐳 v20.10.14 
➜ hanami db reset
=> database timetracker dropped
=> database timetracker created
=> database timetracker migrated in 0.2788s

hanami-timetracker on  main [!?] is 📦 v1.0.0 via ⬢ v16.14.2 via 💎 v3.1.2 on 🐳 v20.10.14 
➜ hanami db version                             
=> current schema version is 20220422184849_create_items_table

hanami-timetracker on  main [!?] is 📦 v1.0.0 via ⬢ v16.14.2 via 💎 v3.1.2 on 🐳 v20.10.14 
➜ hanami db create_migration test_migration
=> migration 20220426195743_test_migration created in 0.0001s

hanami-timetracker on  main [!?] is 📦 v1.0.0 via ⬢ v16.14.2 via 💎 v3.1.2 on 🐳 v20.10.14 
➜ hanami db version
/home/benjamin/.gem/ruby/3.1.2/gems/rom-sql-3.5.0/lib/rom/sql/migration.rb:62:in `migration': undefined method `migration' for nil:NilClass (NoMethodError)

          current_gateway.migration(&block)
                         ^^^^^^^^^^
        from /home/benjamin/dev/github/hanami-timetracker/db/migrate/20220426195743_test_migration.rb:3:in `<top (required)>'
        from /home/benjamin/.gem/ruby/3.1.2/gems/sequel-5.55.0/lib/sequel/extensions/migration.rb:493:in `load'
        from /home/benjamin/.gem/ruby/3.1.2/gems/sequel-5.55.0/lib/sequel/extensions/migration.rb:493:in `block in load_migration_file'
        from /home/benjamin/.gem/ruby/3.1.2/gems/sequel-5.55.0/lib/sequel/extensions/migration.rb:491:in `synchronize'
        from /home/benjamin/.gem/ruby/3.1.2/gems/sequel-5.55.0/lib/sequel/extensions/migration.rb:491:in `load_migration_file'
        from /home/benjamin/.gem/ruby/3.1.2/gems/sequel-5.55.0/lib/sequel/extensions/migration.rb:763:in `block in get_migration_tuples'
        from /home/benjamin/.gem/ruby/3.1.2/gems/sequel-5.55.0/lib/sequel/extensions/migration.rb:751:in `each'
        from /home/benjamin/.gem/ruby/3.1.2/gems/sequel-5.55.0/lib/sequel/extensions/migration.rb:751:in `get_migration_tuples'
        from /home/benjamin/.gem/ruby/3.1.2/gems/sequel-5.55.0/lib/sequel/extensions/migration.rb:680:in `initialize'
        from /home/benjamin/.gem/ruby/3.1.2/bundler/gems/cli-752cc5d64bbd/lib/hanami/cli/commands/db/utils/database.rb:114:in `new'
        from /home/benjamin/.gem/ruby/3.1.2/bundler/gems/cli-752cc5d64bbd/lib/hanami/cli/commands/db/utils/database.rb:114:in `sequel_migrator'
        from /home/benjamin/.gem/ruby/3.1.2/bundler/gems/cli-752cc5d64bbd/lib/hanami/cli/commands/db/utils/database.rb:105:in `applied_migrations'
        from /home/benjamin/.gem/ruby/3.1.2/bundler/gems/cli-752cc5d64bbd/lib/hanami/cli/commands/monolith/db/version.rb:16:in `call'
        from /home/benjamin/.gem/ruby/3.1.2/bundler/gems/cli-752cc5d64bbd/lib/hanami/cli/commands/application.rb:19:in `call'
        from /home/benjamin/.gem/ruby/3.1.2/gems/dry-cli-0.7.0/lib/dry/cli.rb:116:in `perform_registry'
        from /home/benjamin/.gem/ruby/3.1.2/gems/dry-cli-0.7.0/lib/dry/cli.rb:65:in `call'
        from /home/benjamin/.gem/ruby/3.1.2/gems/hanami-cli-2.0.0.alpha7/exe/hanami:10:in `<top (required)>'
        from /home/benjamin/.gem/ruby/3.1.2/bin/hanami:25:in `load'
        from /home/benjamin/.gem/ruby/3.1.2/bin/hanami:25:in `<main>'

hanami-timetracker on  main [!?] is 📦 v1.0.0 via ⬢ v16.14.2 via 💎 v3.1.2 on 🐳 v20.10.14 
➜ hanami db migrate
=> database timetracker migrated in 0.2391s

hanami-timetracker on  main [!?] is 📦 v1.0.0 via ⬢ v16.14.2 via 💎 v3.1.2 on 🐳 v20.10.14 
➜ hanami db version
=> current schema version is 20220426195743_test_migration

I'm facing the same issue for the new command I'm trying to implement and will investigate why this is appearing.

EDIT:

Using hanami-cli github main branch.

# frozen_string_literal: true

source "https://rubygems.org/"

# Core gems
gem "rake", "~> 13.0"

# Application framework
gem "hanami", "~> 2.0.0.alpha"
# gem "hanami-cli", "~> 2.0.0.alpha"
gem "hanami-cli", github: "hanami/cli"
# gem "hanami-cli", path: "../cli"
gem "hanami-controller", "~> 2.0.alpha"
gem "hanami-router", "~> 2.0.0.alpha"
gem "hanami-utils", "~> 2.0.0.alpha"
gem "hanami-view", "~> 2.0.0.alpha"

Generate db files in `generate slice`

With these options:

--skip-db to skip DB setup
--app-db to share the app’s DB setup
--slice-db to use a distinct database setup, generating config/db/ in the slice
--database=sqlite to use an sqlite database (the default) (relevant only for --slice-db)
--database=postgres to use a postgres database (relevant only for --slice-db)

When generating an action and it is a "RESTful" create, update, or delete, do not generate a view if a counterpart view already exists

We should expect these actions to rely on “new” and “edit” views, so they shouldn’t need their own.

Add note about different commands within and outside of app

We only allow hanami new outside of existing Hanami projects, and only allow almost all the other commands inside a Hanami 2 project (version is rightfully allowed in both).

For example:

% hanami version
v2.0.0.beta3
% hanami help
Commands:
  hanami new APP
  hanami version
% hanami new beta_three
% cd beta_three
% hanami help
Commands:
  hanami console                              # App REPL
  hanami generate [SUBCOMMAND]
  hanami install
  hanami middlewares                          # List all the registered middlewares
  hanami routes                               # Inspect application
  hanami server
  hanami version

Something like: "There are more commands available when you're inside of an app, but we've detected that you're not in a Hanami 2 folder". We could even list them (on one line, without descriptions) too. And when inside an app something like "hanami new is also available when you're outside of an existing Hanami project folder."

I think this could be a "good first issue" for newcomers who'd like to contribute to the Hanami 2 effort.

Incorrect module names when generating a new project

I was trying Hanami 2.0.0 beta for my side project. When generating a new project, If the project name ends with a s it is being ignored by hanami new command.

Eg:

bundle exec hanami new rubygems

And the generated module name is not consistent with the project name.
lib/rubygems/types.rb

# frozen_string_literal: true

require "dry/types"

module Rubygem
  Types = Dry.Types

  module Types
    # Define your custom types here
  end
end

Add `db structure dump` command

$ bundle exec hanami db structure dump # Dumps the structure for all databases
$ bundle exec hanami db structure dump --app # Dumps the structure for the app database
$ bundle exec hanami db structure dump --slice=billing # Dumps the structure for the "billing" slice database

Note: this already exists as a command, but it has been disabled for a while. It just needs to be reactivated, and updated for the per-slice behaviour.

cli does not works when using hanami 2.0-alpha releases

Hi,

I am trying to run an Hanami app with 2.0-alpha releases and I am not able to run any command.
For each command I tried I had the following result:

➜  cockpit git:(master) ✗ bundle exec hanami server                                                                                                                      [2.7.3]
Commands:
  hanami version

My gemfile

source 'https://rubygems.org'

gem 'rake'
gem 'hanami-model'
%w[hanami hanami-cli hanami-controller hanami-router hanami-utils hanami-view].each do |name|
  gem name, "~> 2.0.alpha"
end

gem 'sqlite3'
...

I use ruby 2.7.3
For your information when I downgrade to 1.3.4 everything works.

Do you have any idea why it does not work as expected ?

Many thanks.

Add `db version` command

$ bundle exec hanami db version # Prints all database versions
$ bundle exec hanami db version --app # Prints app database version
$ bundle exec hanami db version --slice=billing # Prints "billing" slice database version

Note: this already exists as a command, but it has been disabled for a while. It just needs to be reactivated, and updated for the per-slice behaviour.

db migrate should also run db structure dump

Unable to create migrations

Hi,

I am following the Hanami introduction and I tried to generate a migration but it turns out that I have this error.

➜  bookshelf git:(main) ✗ bundle exec rake db:create_migration\[create_books\]
rake aborted!
Don't know how to build task 'db:create_migration' (See the list of available tasks with `rake --tasks`)
/Users/user/.rbenv/versions/3.3.0/bin/bundle:25:in `load'
/Users/user/.rbenv/versions/3.3.0/bin/bundle:25:in `<main>'
(See full trace by running task with --trace)

I am unable to generate a migration. Do you have any insights into why it is not working?
More generally I don't have access to the hanami/cli commands and I am not sure why.

FYI my gemfile (I have also try to add gem "hanami-cli" with the same result)

# frozen_string_literal: true

source "https://rubygems.org"

gem "hanami", "~> 2.0"
gem "hanami-router", "~> 2.0"
gem "hanami-controller", "~> 2.0"
gem "hanami-validations", "~> 2.0"

gem "dry-types", "~> 1.0", ">= 1.6.1"
gem "puma"
gem "rake"
gem "pry-byetypo"
gem "pry"
gem "rom", "~> 5.3"
gem "rom-sql", "~> 3.6"
gem "pg"
  
group :development, :test do
  gem "dotenv"
end

group :cli, :development do
  gem "hanami-reloader"
end

group :cli, :development, :test do
  gem "hanami-rspec"
end

group :development do
  gem "guard-puma", "~> 0.8"
end

group :test do
  gem "rack-test"
end

Thanks!

Namespaced action generates incorrect `to` option

Running:

hanami g api/users.thing

Gives me a route:

get "/api/users/thing", to: "api/users.thing"

When loading the Hanami app through hanami s (http://localhost:2300), I see this error:

Puma caught this error: Could not find action with key "actions.api/users.thing" in Chirper::App

To fix this, define the action class Chirper::Actions::API::Users::Thing in /Users/ryan.bigg/code/chirper/actions/api/users/thing.rb
 (Hanami::Routes::MissingActionError)

However, in hanami console:

Chirper::App.key?("actions.api/users.thing") #=> true

The same is true if I replace the dots with slashes in that.

So why is it then that the router cannot find this action? Should the route that is generated be api.users.thing instead of api/users.thing?

$ bundle exec hanami db prepare # Prepares all databases
$ bundle exec hanami db prepare --app # Prepares app database
$ bundle exec hanami db prepare --slice=billing # Prepares "billing" slice database

hanami / cli Goto Github PK

cli's Introduction

Hanami 🌸

Version

Frameworks

Status

Installation

Usage

Donations

Supporters

Contact

Community

Contributing

Tests

Development Requirements

Versioning

Copyright

cli's People

Contributors

Stargazers

Watchers

Forkers

cli's Issues

Background

Steps to reproduce

What I tried to do:

What I expected to happen:

What actually happened:

Recommend Projects

Recommend Topics

Recommend Org