Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Config system is usable by itself. Separate the Config system to its own project.

Open
  • Is something wrong?
#1,756 2 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Stale
Tech stack
perl
Domain
tooling

Research direction

Start by tracing Dancer2::ConfigReader and the Dancer2::Core roles used by Util::Config::DancerLikeConfig. Identify the dependencies that prevent the configuration system from standing alone and define the distribution boundary. Done means the configuration functionality can be used by other applications without loading the whole Dancer2 framework.

Written by the indexing model from the issue text.

Description

Question

Could we separate the configuration system into its own distribution?

Dancer2's config system is quite usable for a serious business application. It is straightforward and clear, and still allows different configurations for different environment type, deployments and local special cases.

In my own applications I have many services: Dancer2 webservices, TheSchwarz worker queue, daemons, and others. Also database migration scripts and others. They all use the same configuration. When starting, they use DancerLikeConfig which is a module I programmed so that I would not need to include all of Dancer2 hierarchy into the program. But it still includes a lot, especially Dancer2::Core.

It would be great to be able to use only the configuration, not the whole of Dancer2. Loading everything takes time, sometimes seconds.

Name proposals: "App-Config-Dancer2", "App-Config-Modern", "App-Config-Deployments".

My DancerLikeConfig:
package Util::Config::DancerLikeConfig;
use strict;
use warnings;

use Moo;
use Dancer2::ConfigReader;
use Dancer2::Core::Types;

with qw<
      Dancer2::Core::Role::HasConfig
      Dancer2::Core::Role::HasLocation
      Dancer2::Core::Role::HasEnvironment
>;

has config_reader => (
    is      => 'lazy',
    isa     => InstanceOf['Dancer2::ConfigReader'],
);

sub _build_config_reader { ## no critic (Subroutines::ProhibitUnusedPrivateSubroutines)
    my ($self) = @_;
    my $cfgr = Dancer2::ConfigReader->new(
        environment    => $self->environment,
        location       => $ENV{DANCER_CONFDIR}     || $self->location,
        # default_config => $self->_build_default_config(),
        default_config => {},
    );
    return $cfgr;
}

has '+config' => (
    is      => 'lazy',
    isa     => HashRef,
);

sub _build_config { ## no critic (Subroutines::ProhibitUnusedPrivateSubroutines)
    my ($self) = @_;

    my $config_reader = $self->config_reader;
    my $config = $config_reader->config;

   return $config;
}

1;
Dominant language
Perl
Stars
604
Forks
287
Avg merge
1d 9h
Merged PRs (30d)
6

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from PerlDancer/Dancer2

All issues in PerlDancer/Dancer2

Similar issues

More Perl issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.