Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ensure naming of files during app and dockerfile generation is consistent #1918

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
4 changes: 2 additions & 2 deletions lib/Mojolicious.pm
Expand Up @@ -35,7 +35,7 @@ has log => sub {
};
has 'max_request_size';
has mode => sub { $ENV{MOJO_MODE} || $ENV{PLACK_ENV} || 'development' };
has moniker => sub { Mojo::Util::decamelize ref shift };
has moniker => sub { Mojo::Util::class_to_file ref shift };
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a breaking change unfortunately. This has implications about how configuration files are loaded by default. I'd be fine changing this at a major version or at least in line with our breaking changes rules (though I would personally rather this be at a major version)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a process I should follow to put this forward for a major release?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While I support your stance @jberger that this is a breaking change and thus should be planned for a major release, it is also a question of definition: is the proposed change a change or a bugfix?

When looking over a couple of projects here I see that we usually end up overriding moniker because of how the default moniker is generated (see example table from the PR description). So from that perspective if this change was to be implemented we no longer would have to set moniker in our apps, because the problem with the auto-generated moniker would go away.

From that perspective I think it is fair to view this as a bugfix, and thus be considered for a minor-release.

has plugins => sub { Mojolicious::Plugins->new };
has preload_namespaces => sub { [] };
has renderer => sub { Mojolicious::Renderer->new };
Expand Down Expand Up @@ -425,7 +425,7 @@ variables or C<development>.
$app = $app->moniker('foo_bar');

Moniker of this application, often used as default filename for configuration files and the like, defaults to
decamelizing the application class with L<Mojo::Util/"decamelize">.
transforming the application class with L<Mojo::Util/"class_to_file">.

=head2 plugins

Expand Down
2 changes: 1 addition & 1 deletion lib/Mojolicious/Command/Author/generate/app.pm
Expand Up @@ -19,7 +19,7 @@ sub run {
$self->render_to_rel_file('appclass', "$name/lib/$app", {class => $class});

# Config file (using the default moniker)
$self->render_to_rel_file('config', "$name/@{[decamelize $class]}.yml");
$self->render_to_rel_file('config', "$name/$name.yml");

# Controller
my $controller = "${class}::Controller::Example";
Expand Down
2 changes: 1 addition & 1 deletion t/mojo/daemon.t
Expand Up @@ -270,7 +270,7 @@ subtest 'Timeout' => sub {
subtest 'Pipelined' => sub {
my $daemon = Mojo::Server::Daemon->new({listen => ['http://127.0.0.1'], silent => 1});
my $port = $daemon->start->ports->[0];
is $daemon->app->moniker, 'mojo-hello_world', 'right moniker';
is $daemon->app->moniker, 'mojo_hello_world', 'right moniker';
my $buffer = '';
my $id;
$id = Mojo::IOLoop->client(
Expand Down