staticky 0.1.1 → 0.3.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 601e3b52395f847f7f7f57909a0063f83063dc0cf5bd02ef21e865d972f3322f
-  data.tar.gz: 7d8ecdd8e166359930743d01e2c955dc521a4f9d1b231d239d35aa45858cc003
+  metadata.gz: 65d9999164be324b93ee59cb6602a46b0c703e6e5f543801d4173164644e3ae9
+  data.tar.gz: '0834f3f08d1d8cf469b846cec8349e5427c0809a419cbeaf845bf8ed66e07535'
 SHA512:
-  metadata.gz: c1b21ab89e9d6429b3cd3407ae84802c1739e68aa39c969f10c0d82e28ad3cdf187cd1bedcf98a22805fbe9de64c3be96d711f4f554c5addf55c744bcd11b9a6
-  data.tar.gz: 3695cab76d925bec1ba6e02852ac63a088c88cd2d2fb9e3942c5e33f0ef8aefb19d6c643c6e2ade7d63b438dba6d954a351efaba86939ac4ac5e56be73652343
+  metadata.gz: d762bb547a713f7c86e4de541c1ee81615b8d0b5ec6d70633b50a1ad77986addf27ae64b3fc133c7b9749267774093ff9c9b1c6be54c8294004503b7992b6e9b
+  data.tar.gz: 1103439135f08b7558e51eaf8a147febf2924f333f7f8b4b4c84ceeed24173d84c8ddc40d8aa4e25dd4fa4877a30a4b40bf37e3c14d23f78bac3391f1da324c2

data/.rubocop.yml

@@ -9,3 +9,6 @@ inherit_gem:
 
 AllCops:
   TargetRubyVersion: 3.3
+
+Lint/NumberConversion:
+  Enabled: false

data/CHANGELOG.md

@@ -1,5 +1,19 @@
 ## [Unreleased]
 
+## [0.3.0] - 2024-12-09
+
+- Adds live reloading of pages during development using server side events
+- Integrates live reloading with vite in site template
+
+## [0.2.0] - 2024-09-24
+
+- Adds plugin system akin to Roda and Sequel for `Resource` and `Router`
+- Improves initial setup
+- Adds better documentation
+- Switches from `rerun` to `filewatcher` for triggering rebuilds
+- Switches from `rackup` to `puma` for development server
+- Updates default package manager to yarn stable
+
 ## [0.1.1] - 2024-08-18
 
 - Fixes nginx and Dockerfile configs for default dokku deployments

data/README.md

@@ -8,7 +8,7 @@ first-class support for Phlex components.
 I wanted to extend the developer experience of something like Rails but focused
 on static sites.
 
-I am using this at https://taintedcoders.com. (soon)
+I am currently using this to create https://taintedcoders.com
 
 - Hot reloading in development with Roda serving static files
 - Docker deployment with NGINX
@@ -36,14 +36,151 @@ staticky new my_blog --url "https://example.com"
 This will generate a new site at `./my_blog`, install your dependencies and run
 `rspec` just to make sure everything got set up correctly.
 
+You can append `--help` to any commands to see info:
+
+```
+staticky new --help
+```
+
+Which outputs:
+
+```
+Command:
+  staticky new
+
+Usage:
+  staticky new PATH
+
+Description:
+  Create new site
+
+Arguments:
+  PATH                              # REQUIRED Relative path where the site will be generated
+
+Options:
+  --url=VALUE, -u VALUE             # Site URL, default: "https://example.com"
+  --title=VALUE, -t VALUE           # Site title, default: "Example"
+  --description=VALUE, -d VALUE     # Site description, default: "Example site"
+  --twitter=VALUE, -x VALUE         # Twitter handle, default: ""
+  --help, -h                        # Print this help
+```
+
+### Plugins
+
+The router and resources use the plugin
+[pattern](https://janko.io/the-plugin-system-of-sequel-and-roda/)
+found in [Sequel](https://github.com/jeremyevans/sequel) and
+[Roda](https://github.com/jeremyevans/roda).
+
+This means you can easily extend each of them with plugins to fit the specific
+content of your site.
+
+```ruby
+module MyResourcePlugin
+  module InstanceMethods
+    def component=(component)
+      @component = component
+    end
+
+    def component
+      return @component if defined?(@component)
+
+      raise ArgumentError, "component is required"
+    end
+  end
+end
+```
+
+In our own classes we can now reference our new plugin:
+
+```ruby
+class SomeResource < Staticky::Resource
+  plugin MyResourcePlugin
+end
+```
+
+Or, if we register the plugin with `register_plugin` we can just use our
+shorter symbol:
+
+```ruby
+Staticky::Resources::Plugins.register_plugin(:something, MyResourcePlugin)
+
+class SomeResource < Staticky::Resource
+  plugin :something
+end
+```
+
+This system lets you define your own specific resources by subclassing and
+extending with your own plugins.
+
+Here is an example of hooking into the output of the component
+(a string of HTML):
+
+```ruby
+module MinifyHTML
+  module InstanceMethods
+    # Calling super works because the base class has no methods, everything is
+    # a plugin including the core behavior of a resource.
+    def build
+      SomehowMinifyTheHTML.call(super)
+    end
+  end
+end
+
+Staticky::Resources::Plugins.register_plugin(:minify_html, MinifyHTML)
+
+class ApplicationResource < Staticky::Resource
+  plugin :minify_html
+end
+```
+
+Now when an `ApplicationResource` gets rendered, its final output (a string of
+HTML) will be minified.
+
+Each plugin can define modules for:
+
+|Name|Description|
+|----|-----------|
+|InstanceMethods|Get added as instance methods of the Resource|
+|ClassMethods|Get added as the class methods of the Resource|
+
+In addition you have methods you can define that let you hook into the resource
+that adds your plugins:
+
+|Name|Description|
+|----|-----------|
+|load_dependencies(plugin, ...)|Hook to load any other plugins required by this one|
+|configure(plugin, ...)|Hook for additional setup required on the class|
+
+
+### Routing
+
+Your router is a plugin system that by default only has one plugin:
+
+```ruby
+plugin :prelude
+```
+
+This gives you the `match` and `root` methods in your router. You can override
+or extend these methods yourself by redefining them (and optionally calling
+`super`) inside your own plugin or class that inherits from the router.
+
 Once your site is generated you can use the router to define how your content
 maps to routes in `config/routes.rb`:
 
 ```ruby
 Staticky.router.define do
   root to: Pages::Home
+
+  # We can pass in a phlex class
   match "404", to: Errors::NotFound
-  match "500", to: Errors::ServiceError
+  # Or an instance
+  match "500", to: Errors::ServiceError.new
+
+  # We can specify the resource type
+  match "about",
+    to: Markdown.new("content/posts/about.md"),
+    as: Resources::Markdown
 
   # Write your own logic to parse your data into components
   Site.posts.each_value do |model|
@@ -56,13 +193,139 @@ Each route takes a Phlex component (or any object that outputs a string from
 `#call`). We can either pass the class for a default initialization (we just
 call `.new`) or initialize it ourselves.
 
+The resource will be initialized with a `component` and a `url`. It is used as
+the view context for your phlex components.
+
+#### Match
+
+This works in a similar way to your Rails routes. Match takes a path and
+a component (either a class or an instance) that it will route to.
+
+```ruby
+match "404", to: Errors::NotFound, as: Resource
+```
+
+#### Root
+
+Using `match` you can define a root path like:
+
+```ruby
+match "/", to: Pages::Home
+```
+
+For convenience you can shorten this using `root`:
+
+```ruby
+root to: Pages::Home
+```
+
+### Resources
+
+They initialize the same way `ActiveModel` objects do. That is they take their
+keywords and call the setter according to the keys:
+
+```ruby
+def new(**env)
+  super().tap do |resource|
+    env.each do |key, value|
+      resource.send(:"#{key}=", value)
+    end
+  end
+end
+```
+
+The base resource has two core plugins it includes by default:
+
+```ruby
+plugin :prelude
+plugin :phlex
+```
+
+Routes define your resources, which in the end are just data objects that
+contain all the information required to produce the static file that eventually
+outputs to your `Staticky.build_path`.
+
+Lets say we had a router defined like:
+
+```ruby
+Staticky.router.define do
+  match "foo", to: Component
+  match "bar", to: Component
+end
+```
+
+Then we could view our resources:
+
+```
+(ruby) Staticky.resources
+[#<Staticky::Resource:0x0000711525d82c18
+  @component=#<Component:0x0000711525d74848>,
+  @destination=#<Pathname:/your-site-folder/build>,
+  @uri=#<URI::Generic /foo>,
+  @url="foo">,
+ #<Staticky::Resource:0x0000711525d82a88
+  @component=#<Component:0x0000711525d74208>,
+  @destination=#<Pathname:/your-site-folder/build>,
+  @uri=#<URI::Generic /bar>,
+  @url="bar">]
+```
+
+The `prelude` plugin provides the following methods:
+
+|Method|Description|
+|------|-----------|
+|`build_path`|`Pathname` of where the component's output will be written to|
+|`read`|Read the output of the resource from the file system|
+|`filepath`|The file path (e.g. `about/index.html`) for the resource|
+|`root?`|Whether or not the resource is the root path|
+
+While the `phlex` plugin provides:
+
+|Method|Description|
+|------|-----------|
+|`build`|Call the component and output its result as a string|
+
+These resources are used by your site builder to output the files that end up in
+the `Staticky.build_path`.
+
+Each resource needs to have a `#build` method that creates a file in your build
+folder.
+
+The `phlex` plugin will call your components with a `ViewContext` just like
+`ActionView` in Rails. But this context is tailored towards your static site.
+
+This view context is a `SimpleDelegator` to your resource with a few extra
+methods:
+
+|Method|Description|
+|------|-----------|
+|`root?`|Whether or not this resource is for the root page|
+|`current_path`|The path of the current resource being rendered|
+
+These are useful for creating pages that hide or show content depending on which
+path of the site we are building.
+
+### Linking to your routes
+
+First you need to include the view helpers somewhere in your component
+hierarchy:
+
+```ruby
+class Component < Phlex::HTML
+  include Staticky::Phlex::ViewHelpers
+end
+```
+
+This will add `link_to` to all your components which uses the router to resolve
+any URLs via their path.
+
 Here is an example of what the `Posts::Show` component might look like. We are
 using a [protos](https://github.com/inhouse-work/protos) component, but you can
 use plain old Phlex components if you like.
 
 ```ruby
 module Posts
-  class Show < Protos::Component
+  class Show < ApplicationComponent
     param :post, reader: false
 
     def around_template(&)
@@ -70,7 +333,12 @@ module Posts
     end
 
     def view_template
-      link_to "Home", "/"
+      # Links can be resolved to component classes if they are unique:
+      link_to "Home", Pages::Home
+      # They can also resolve via their url:
+      link_to "Posts", "/posts"
+      # Absolute links are resolved as is:
+      link_to "Email", "mailto:email@example.com"
 
       render Posts::Header.new(@post)
       render Posts::Outline.new(@post, class: css[:outline])
@@ -82,28 +350,37 @@ module Posts
 
     def theme
       {
-        layout: "mr-0 lg:mr-[--sidebar-width] md:ml-[--sidebar-width]",
-        outline: %w[
-          my-md
-          md:fixed
-          md:left-0
-          md:top-[--navbar-height]
-          md:pl-[--viewport-padding]
-          md:w-[--sidebar-width]
-        ],
-        post: "prose mx-auto pb-lg"
+        layout: "bg-background",
+        outline: "border",
+        post: "max-w-prose mx-auto"
       }
     end
   end
 end
 ```
 
-We get `link_to` from the `Staticky::Phlex::ViewHelpers` which resolves either
-a URL or a phlex class from your router.
+The advantage of using `link_to` over plain old `a` tags is that changes to your
+routes will raise errors on invalidated links instead of silently
+linking to invalid pages.
+
+If your component is unique then you can link directly to them (if its not
+unique then it will link to the last defined `match`):
+
+```ruby
+link_to("Some link", Pages::Home)
+```
+
+Otherwise you can link to the path itself:
+
+```ruby
+link_to("Some link", "/")
+```
+
+### Building your site
 
 When you are developing your site you run `bin/dev` to start your development
-server on http://localhost:9292. This will automatically reload after a short
-period when you make changes.
+server on [http://localhost:3000](http://localhost:3000).
+This will automatically reload after a short period when you make changes.
 
 Assets are handled by Vite by default, but you can have whatever build process
 you like just by tweaking `Procfile.dev` and your `Rakefile`. You will also need
@@ -140,6 +417,18 @@ These are available in your Phlex components under `helpers` (if you are using
 the site template). This matches what you might expect when using Phlex in
 Rails with `phlex-rails`.
 
+## Live reloading
+
+The development server has been hooked up with some live reloading using
+server-side events.
+
+A javascript script is inserted into the `<head>` tag during development which
+will poll the `_staticky/live_reloading` endpoint. If files have changed then
+a reload is triggered with `Turbo` if available, and just plain
+`window.location.reload()` if not.
+
+You can toggle this off by setting `live_reloading` to false inside the config.
+
 ## Configuration
 
 We can override the configuration according to the settings defined on the main
@@ -152,6 +441,77 @@ Staticky.configure do |config|
   config.root_path = Pathname(__dir__)
   config.logger = Logger.new($stdout)
   config.server_logger = Logger.new($stdout)
+  config.live_reloading = false
+end
+```
+
+### Environment
+
+You can define the environment of Staticky through its config.
+
+```ruby
+Staticky.configure do |config|
+  config.env = :test
+end
+```
+
+This lets you write environment specific code:
+
+```ruby
+if Staticky.env.test?
+  # Do something test specific
+end
+```
+
+## Testing
+
+We can setup a separate testing environment by putting the following
+into your `spec/spec_helper.rb`:
+
+```ruby
+Staticky.configure do |config|
+  config.root_path = Pathname.new(__dir__).join("fixtures")
+  config.build_path = Pathname.new(__dir__).join("fixtures/build")
+  config.env = :test
+end
+```
+
+This sets up our build path to something different than our development builds.
+
+Staticky uses `Dry::System` to manage its dependencies which means you can stub
+them out if you want:
+
+```ruby
+require "dry/system/stubs"
+
+Staticky.application.enable_stubs!
+
+RSpec.configure do |config|
+  config.before do
+    Staticky.application.stub(:files, Staticky::Filesystem.test)
+  end
+end
+```
+
+This lets you test your builds using `dry-files` (actually `staticky-files`, but
+the interface is the same with additional capabilities for file folders).
+
+The advantage of this is that we can perform our builds on a temporary in memory
+file system rather than actually writing to our disk.
+
+The plugins themselves can also be stubbed:
+
+```ruby
+require "dry/system/stubs"
+
+Staticky::Resources::Plugins.enable_stubs!
+Staticky::Routing::Plugins.enable_stubs!
+
+RSpec.configure do |config|
+  config.before do
+    Staticky::Resources::Plugins.stub(:prelude, MyOwnResourcePlugin)
+    Staticky::Routing::Plugins.stub(:prelude, MyOwnRoutingPlugin)
+  end
 end
 ```
 

data/lib/staticky/application.rb

@@ -0,0 +1,36 @@
+# frozen_string_literal: true
+
+module Staticky
+  class Application < Dry::System::Container
+    # This class coordinates the booting process to add our dependencies.
+    # We use zeitwerk to autoload our constants in the lib/staticky folder.
+    #
+    # Monitoring is enabled to hook into calls to certain dependencies.
+    #
+    # ```ruby
+    # Staticky.application.monitor(:builder, methods: %i[call]) do |event|
+    #   Staticky.logger.info "Built site in #{event[:time]}ms"
+    # end
+    # ```
+
+    use :zeitwerk
+    use :monitoring
+
+    configure do |config|
+      config.root = Pathname(__dir__).join("..").join("..")
+      config.inflector = Dry::Inflector.new do |inflections|
+        inflections.acronym("CLI")
+      end
+      config.component_dirs.add "lib" do |dir|
+        dir.add_to_load_path = false
+        dir.auto_register = false
+        dir.namespaces.add "staticky", key: nil
+      end
+    end
+
+    register(:files, memoize: true) { Staticky::Filesystem.real }
+    register(:router, memoize: true) { Staticky::Router.new }
+    register(:builder, memoize: true) { Staticky::Builder.new }
+    register(:generator) { Staticky::Generator.new }
+  end
+end

data/lib/staticky/builder.rb

@@ -2,7 +2,9 @@
 
 module Staticky
   class Builder
-    include Dry::Events::Publisher[:builder]
+    # Publisher needs to have a different name vs the application monitor
+    # https://github.com/dry-rb/dry-events/issues/6
+    include Dry::Events::Publisher[:building]
     include Deps[:files, :router]
 
     register_event("started")
@@ -28,7 +30,7 @@ module Staticky
         .resources
         .each do |resource|
           publish("before_resource", resource:)
-          compile output_path(resource.filepath), resource.build
+          compile resource.build_path, resource.build
           publish("after_resource", resource:)
         end
     end

data/lib/staticky/cli/commands/build.rb

@@ -0,0 +1,13 @@
+# frozen_string_literal: true
+
+module Staticky
+  module CLI
+    module Commands
+      class Build < Dry::CLI::Command
+        desc "Build site"
+
+        def call(*) = Staticky.builder.call
+      end
+    end
+  end
+end

data/lib/staticky/cli/commands/generate.rb

@@ -0,0 +1,67 @@
+# frozen_string_literal: true
+
+module Staticky
+  module CLI
+    module Commands
+      class Generate < Dry::CLI::Command
+        desc "Create new site"
+
+        argument :path,
+                 required: true,
+                 desc: "Relative path where the site will be generated"
+
+        option :url,
+               default: "https://example.com",
+               desc: "Site URL",
+               aliases: ["-u"]
+        option :title,
+               default: "Example",
+               desc: "Site title",
+               aliases: ["-t"]
+        option :description,
+               default: "Example site",
+               desc: "Site description",
+               aliases: ["-d"]
+        option :twitter,
+               default: "",
+               desc: "Twitter handle",
+               aliases: ["-x"]
+
+        def call(path:, **)
+          path = Pathname.new(path).expand_path
+
+          Staticky.generator.call(path, **)
+
+          Dir.chdir(path) do
+            system("cd #{path}")
+            system("chmod +x bin/*")
+            bundle_command("install")
+            bundle_command("exec bin/setup")
+          end
+        end
+
+        def bundle_command(command, env = {})
+          puts "bundle #{command}"
+
+          # We are going to shell out rather than invoking Bundler::CLI.new(command)
+          # because `rails new` loads the Thor gem and on the other hand bundler uses
+          # its own vendored Thor, which could be a different version. Running both
+          # things in the same process is a recipe for a night with paracetamol.
+          #
+          # Thanks to James Tucker for the Gem tricks involved in this call.
+          _bundle_command = Gem.bin_path("bundler", "bundle")
+
+          require "bundler"
+          Bundler.with_original_env do
+            exec_bundle_command(_bundle_command, command, env)
+          end
+        end
+
+        def exec_bundle_command(bundle_command, command, env)
+          full_command = %("#{Gem.ruby}" "#{bundle_command}" #{command})
+          system(env, full_command)
+        end
+      end
+    end
+  end
+end

data/lib/staticky/cli/commands/version.rb

@@ -0,0 +1,13 @@
+# frozen_string_literal: true
+
+module Staticky
+  module CLI
+    module Commands
+      class Version < Dry::CLI::Command
+        desc "Print version"
+
+        def call(*) = puts VERSION
+      end
+    end
+  end
+end

data/lib/staticky/cli/commands.rb

@@ -0,0 +1,13 @@
+# frozen_string_literal: true
+
+module Staticky
+  module CLI
+    module Commands
+      extend Dry::CLI::Registry
+
+      register "version", Version
+      register "build", Build
+      register "new", Generate
+    end
+  end
+end