Componentisation proof of concept #9154

This will allow us to define packages and identify where packages have dependencies outside their domain, and manually specify dependencies where necessary https://github.com/Shopify/packwerk

In the next commit, we’ll add a Rails engine to the `packages` directory, which we will autoload on boot. Engines will also contain routes, which we will add to the routes configuration, so we can include routes in the main routes.rb file.

To improve visibility, tests will be included in their relevant pacakages, so we’ll need to ensure all test-related files are included during the test run

This adds the engine code in `lib` to define the engine, and moves the code involved in the Emergency Banner (including the tests) to the package directory, shaped as a mini-Rails app. The routes for this package are defined in a routes file, and then loaded in the main routes file with the `draw` method. We also define a package in package.yml that tells Packwerk to enforce dependencies. Running `packwerk update-todo` adds a `package_todo.yml` file, which shows us where dependencies are being loaded in from other parts of the application.

This can eventually contain all code that other packages depend on, including base controllers, models and some components that are used across the application. We can now define the base package and dependencies in our package and run `packwerk update-todo`, which removes the `package-todo` file in our exiting package. We also update our root application to enforce dependencies and add the base package as a dependency. This ensures that the root application doesn’t use any code in any of our packages, unless a dependency is defined.

There is an open bug in Packwerk when shorthand hash syntax is used in views (Shopify/packwerk#278). Adding brackets seems to fix it

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Componentisation proof of concept #9154

Componentisation proof of concept #9154

Commits on Jun 17, 2024