Crystal脚本引入大量依赖：是否有替代多require语句的更佳方案？

Great question! When building a web framework in Crystal, dealing with a mountain of require statements in every script is definitely a pain—luckily, there are several clean, scalable ways to avoid this clutter. Let’s break down the best approaches:

1. Create a Centralized Bootstrap File #

This is the most common and straightforward solution for framework development. Create a single "entry point" file that imports all your core dependencies (both internal and external), then have every other script in your project require just this one file.

For example, make a src/my_framework/init.cr file:

# Import external shards
require "http/server"
require "json"
require "kemal-session" # Example third-party dependency

# Import your framework's internal modules
require "./router"
require "./controller/base"
require "./middleware/*"
require "./views/helpers"

Then, in any other script (like src/my_framework/app.cr or user-facing example files), you only need one line:

require "./my_framework/init"

This keeps your codebase clean and makes it easy to add/remove dependencies from a single, maintainable location.

2. Use the require_all Shard for Bulk Directory Imports #

If your framework has a consistent directory structure with lots of internal modules, the require_all shard can save you from writing individual require lines for every file. It lets you recursively load all .cr files in a directory (or matching a glob pattern).

First, add it to your shard.yml:

dependencies:
  require_all:
    github: crystal-community/require_all

Then, in your bootstrap file (or directly in scripts), use it like this:

require "require_all"
require_all "./my_framework/middleware" # Loads all files in middleware/
require_all "./my_framework/controllers/**" # Loads all controllers and subdirectories

Just be careful with this approach—make sure your directory structure doesn't include test files or utility scripts you don't want loaded automatically, as it will pull everything matching the pattern.

3. Leverage Crystal's Module System for Implicit Dependencies #

Structure your framework around a top-level module, and have the module's main file import all its submodules. This way, users (or your internal scripts) only need to require the top-level module to access all its components.

For example, in src/my_framework.cr:

module MyFramework
  # Import all submodules internally
  require "./my_framework/router"
  require "./my_framework/controller"
  require "./my_framework/middleware"

  # Expose submodules at the top level for convenience
  Router = MyFramework::Router
  Controller = MyFramework::Controller
  Middleware = MyFramework::Middleware
end

Now, any script can just do:

require "./my_framework"
# Then use components directly:
router = MyFramework::Router.new

This creates a clean, cohesive API for your framework while hiding the messy require logic from end users.

4. Separate Environments with Targeted Bootstrap Files #

If your framework has different dependencies for development, testing, and production, create environment-specific bootstrap files. For example:

• init_dev.cr: Includes debug tools, test helpers, and hot-reload dependencies
• init_prod.cr: Only includes minimal, production-ready dependencies
• init_test.cr: Loads testing frameworks and mock utilities

Then, use Crystal's conditional compilation to load the right one:

{% if flag?(:development) %}
  require "./my_framework/init_dev"
{% elsif flag?(:test) %}
  require "./my_framework/init_test"
{% else %}
  require "./my_framework/init_prod"
{% end %}

This ensures you're only loading what's necessary for each environment, keeping your builds lean.

Quick Notes to Keep in Mind #

• Avoid overloading bulk imports: While require_all is convenient, it can make it harder to track exactly what's loaded—use it for well-organized directories where every file is a core part of the framework.
• Keep bootstrap files focused: Don't cram unrelated dependencies into your main init file; split them into logical groups if needed.
• Test thoroughly: When changing how dependencies are loaded, make sure all components still work as expected—missing require statements can cause runtime errors that are tricky to debug.

内容的提问来源于stack exchange，提问作者ol'bob dole