bridgetownrb / bridgetown Goto Github PK

Adding this at the behest of @svoop to request investigation of what it would take to support new template engines. There were attempts in the past to try adding support to Jekyll for other templates, but it was sort of janky and Liquid was still involved sometimes which seems…weird…so maybe we can give it a fresh look.

Full disclosure: this isn't a feature I'm personally chomping at the bit for, but I obviously want to do right by the community. If you have strong feelings on the subject, please chime in folks! 😃

Bridgetown Version:
0.15.0-beta2

To Reproduce
I have the following test:

require "test_helper"
require "fileutils"
require 'bundler'

CURRENT_BRIDGETOWN_VERSION = '0.15.0.beta2'
# CURRENT_BRIDGETOWN_VERSION = '0.14.0'

class IntegrationTest < Minitest::Test
  def test_it_works
      Rake.rm_rf(TEST_APP)
      Rake.mkdir_p(TEST_APP)
      Rake.cd(TEST_APP)

      File.open(TEST_APP_GEMFILE, 'a') do |file|
        file << "gem 'bridgetown', '~> #{CURRENT_BRIDGETOWN_VERSION}'"
      end

    Bundler.with_unbundled_env do
      Rake.sh("bundle install")
      Rake.sh("bundle exec bridgetown new . --force")
    end
  end
end

Current behavior

I receive the following error:

➜  bridgetown-plugin-tailwindcss git:(automation) ✗ rake test
Run options: --seed 3142

# Running:

rm -rf /home/krog/projects/ruby/bridgetown-plugin-tailwindcss/test_app
mkdir -p /home/krog/projects/ruby/bridgetown-plugin-tailwindcss/test_app
cd /home/krog/projects/ruby/bridgetown-plugin-tailwindcss/test_app
bundle install
Using concurrent-ruby 1.1.6
Using i18n 1.8.2
Using minitest 5.14.1
Using thread_safe 0.3.6
Using tzinfo 1.2.7
Using zeitwerk 2.3.0
Using activesupport 6.0.3.1
Using public_suffix 4.0.5
Using addressable 2.7.0
Using colorator 1.1.0
Using multipart-post 2.1.1
Using faraday 1.0.1
Using faraday_middleware 1.0.0
Using rexml 3.2.4
Using kramdown 2.2.1
Using kramdown-parser-gfm 1.1.0
Using liquid 4.0.3
Using safe_yaml 1.0.5
Using liquid-component 0.1.0
Using liquid-render-tag 0.2.0
Using rb-fsevent 0.10.4
Using ffi 1.12.2
Using rb-inotify 0.10.1
Using listen 3.2.1
Using forwardable-extended 2.6.0
Using pathutil 0.16.2
Using rouge 3.19.0
Using unicode-display_width 1.7.0
Using terminal-table 1.8.0
Using thor 1.0.1
Using bridgetown-core 0.15.0.beta2
Using bridgetown-builder 0.15.0.beta2
Using bridgetown-paginate 0.15.0.beta2
Using bridgetown 0.15.0.beta2
Using bundler 2.1.4
Bundle complete! 1 Gemfile dependency, 35 gems now installed.
Use `bundle info [gemname]` to see where a bundled gem is installed.

bundle exec bridgetown new . --force

bundler: failed to load command: bridgetown (/home/krog/.gem/ruby/2.6.3/bin/bridgetown)
LoadError: cannot load such file -- active_support/core_ext/array/extract_options
  /home/krog/.gem/ruby/2.6.3/gems/bridgetown-core-0.15.0.beta2/lib/bridgetown-core/commands/concerns/actions.rb:4:in `require'
  /home/krog/.gem/ruby/2.6.3/gems/bridgetown-core-0.15.0.beta2/lib/bridgetown-core/commands/concerns/actions.rb:4:in `<top (required)>'
  /home/krog/.gem/ruby/2.6.3/gems/bridgetown-core-0.15.0.beta2/lib/bridgetown-core.rb:13:in `require'
  /home/krog/.gem/ruby/2.6.3/gems/bridgetown-core-0.15.0.beta2/lib/bridgetown-core.rb:13:in `block in require_all'
  /home/krog/.gem/ruby/2.6.3/gems/bridgetown-core-0.15.0.beta2/lib/bridgetown-core.rb:12:in `each'
  /home/krog/.gem/ruby/2.6.3/gems/bridgetown-core-0.15.0.beta2/lib/bridgetown-core.rb:12:in `require_all'
  /home/krog/.gem/ruby/2.6.3/gems/bridgetown-core-0.15.0.beta2/lib/bridgetown-core/commands/base.rb:3:in `<top (required)>'
  /home/krog/.gem/ruby/2.6.3/gems/bridgetown-core-0.15.0.beta2/bin/bridgetown:21:in `require'
  /home/krog/.gem/ruby/2.6.3/gems/bridgetown-core-0.15.0.beta2/bin/bridgetown:21:in `<top (required)>'
  /home/krog/.gem/ruby/2.6.3/bin/bridgetown:23:in `load'
  /home/krog/.gem/ruby/2.6.3/bin/bridgetown:23:in `<top (required)>'
E

Expected behavior

It should run without errors.

When I change the value of CURRENT_BRIDGETOWN_VERSION to 0.14.0 I do not encounter this error.

Computing environment (please complete the following information):

• OS: Ubuntu 20.04
• Ruby Version 2.6.3

Additional context

Link to latest commit with Error

Also of note, if i cd into the test app and manually run bundle exec bridgetown new . --force it works.

Is it possible that bridgetown could implement or document some sort of basic search capability. I feel this is a very critical aspect of websites that is often overlooked by static site generators.

There should be a standard convention of swapping out parts of configuration or site metadata based on the Bridgetown environment (development, production, testing, etc.) Particularly relevant for plugins so you could easily change remote data URLs or file paths or other context-specific settings.

UPDATE: see #283

Looking through the generated docs from Yard:
https://rubydoc.info/gems/bridgetown-core/

Right now any useful information contained therein is very spotty and some files have no documentation whatsoever. We should prioritize incremental progress towards a fairly complete set of documentation around the core set of Bridgetown objects. Not as worried about ancillary objects like a string utility here or a tag there.

Somewhere along the way the add_yarn_for_gem automation action expected to be able to run Bridgetown's internal yarn add logic only for a specific gem, but that functionality isn't present and there's an arity mismatch on plugin manager's install_yarn_dependencies. Need to clean this up.

Motivation

The official Bridgetown blog/documentation website is nearing completion for a solid first release. This issue will track progress on getting that finished up and online.

Suggestion

Finish…the website…and get it online. 😉

Bridgetown Version:
0.15.0.beta2

To Reproduce

bundle exec bridgetown new newsite
Current behavior

Provides the following warning:

[DEPRECATED] `Bundler.with_clean_env` has been deprecated in favor of 
`Bundler.with_unbundled_env`. If you instead want the environment before bundler was originally loaded, use `Bundler.with_original_env` 
(called at /home/krog/.gem/ruby/2.6.3/gems/bridgetown-core-
0.15.0.beta2/lib/bridgetown-core/commands/new.rb:118)

Computing environment (please complete the following information):

• OS: ubuntu 20.04
• Ruby Version 2.6.3

Additional context

Its only a deprecation warning, can easily be fixed, but wanted to submit an issue before making a PR.

UPDATE: see comment below — planning on rewriting the CLI in Thor.

Similar to how you can do:

gatsby new gatsby-material-starter https://github.com/Vagr9K/gatsby-material-starter

or

rails new my_app -m https://raw.github.com/webBoxio/rails-templates/master/base_template.rb

We'd simply augment the existing bridgetown new command to support a path to a folder or a remote URL like GitHub, and then it could use that instead of the built-in site template. Bonus feature would be to support some kind of simple configuration process to fill-in-the-blanks, but adding an interactive Q&A to the command line seems quite complicated, so we may save that for a future enhancement.

When supplying a branch such as "automation" or "development" to the bridgetown apply command, it appends "master"

Bridgetown Version:

0.15.0.beta-2

Current Behavior:

bridgetown apply https://github.com/ParamagicDev/bridgetown-plugin-tailwindcss/tree/automation/bridgetown.automation.rb

Turns

"https://github.com/ParamagicDev/bridgetown-plugin-tailwindcss/tree/automation/bridgetown.automation.rb"

into

"https://raw.githubusercontent.com/ParamagicDev/bridgetown-plugin-tailwindcss/automation/master/bridgetown.automation.rb"

Expected Behavior

"https://github.com/ParamagicDev/bridgetown-plugin-tailwindcss/tree/automation/bridgetown.automation.rb"

Should turn to

"https://raw.githubusercontent.com/ParamagicDev/bridgetown-plugin-tailwindcss/automation/bridgetown.automation.rb"

Using the console command, if you run site.render and then try to run site.inspect, you get a weird error and the stack trace seems to indicate a problem in the inspect Liquid filter method.

Traceback (most recent call last):
       16: from /Users/jared/apps/BRIDGETOWN/bridgetown/bridgetown-core/lib/bridgetown-core/commands/console.rb:58:in `catch'
       15: from /Users/jared/apps/BRIDGETOWN/bridgetown/bridgetown-core/lib/bridgetown-core/commands/console.rb:59:in `block in console'
       14: from (irb):9
       13: from (irb):9:in `rescue in irb_binding'
       12: from (irb):9:in `inspect'
       11: from (irb):9:in `inspect'
       10: from (irb):9:in `inspect'
        9: from (irb):9:in `inspect'
        8: from (irb):9:in `inspect'
        7: from (irb):9:in `inspect'
        6: from (irb):9:in `inspect'
        5: from (irb):9:in `inspect'
        4: from (irb):9:in `inspect'
        3: from (irb):9:in `inspect'
        2: from (irb):9:in `inspect'
        1: from /Users/jared/apps/BRIDGETOWN/bridgetown/bridgetown-core/lib/bridgetown-core/filters.rb:311:in `inspect'
ArgumentError (wrong number of arguments (given 0, expected 1))

I cannot for the life of me figure out how that particular method gets mixed into site. It doesn't come up with other objects from what I can tell, nor are there any other filters mixed into site. Spooky!

The Prototype pages feature expects Pagination to be enabled, otherwise none of the documents for the generated pages are available automatically. Now it is possible to grab the found term as a variable (e.g., page.category, page.tag, etc.) and load up docs yourself, so technically you can use Prototype pages without Pagination. But after spending some time wondering why the expected behavior wasn't working, only to realize I hadn't turned Pagination on yet, I think this needs some visibility.

For historical reasons, the built-in posts collection is handled in a somewhat unique way (and is read in with a different reader object) compared with custom collections. (For example, you can put a post file in any subfolder or set of nested subfolders within _posts and the URL remains the same because the permalink logic for posts isn't dependent on file path.

It'd be nice to boil that all down into a single code path so that even if the files in _posts behave differently than _some-other-collection, it's simply because of a configuration option. That also opens the doors to custom collections behaving in exactly the same way as _posts if configured.

Pie-in the-sky bonus: turn standalone pages into simply another collection called "pages". It seems strange to have two completely different models for something that in the end feels like the same kind of thing: a URL with rendered content.

Trying out a benchmark with around 2000 posts and the difference with pagination off vs on goes from <10 seconds to around 50 seconds! I've noticed a bunch of data loops in the pagination code that seem ripe for optimization and/or caching, so I'll start there and see if we can knock this build time way down.

I'm wondering what, if anything, we'd need to do to ensure NetlifyCMS and Forestry work with Bridgetown sites. Will the reasonably close similarities to Jekyll help us, or hurt us? (maybe they'll just get hopelessly confused?) Need to do some testing, fix any issues, and then write up documentation.

In iTerm, sometimes when I ctrl-c to quit the dev services, and then I press the up arrow key to browse shell history, instead of seeing the actual commands I just get garbage characters: ^[OA

Wonder if the sync.js script needs to output a newline or something upon termination to get the shell to work correctly.

Update: we ended up opting for a "data cascade" folder-based approach rather than changing the syntax of the defaults key in the config. See #139

I've always found the YAML syntax for defining front matter defaults to be extremely obtuse and I always have to look up a reference to remember how the heck to write it out. Really all I want to do is:

defaults:
  posts:
    layout: post
  pages:
    layout: page
  "some/path/to/stuff":
    category: stuff

Let's make this a whole lot better and then deprecate the old syntax with the goal of removing it for the 1.0 release.

Note: it should be a pretty straightforward swap because the old syntax is array-based, whereas the new one will be hash-based, so we can easily detect which syntax is being used.

On this page it talks about how a Gem-based plugin could be created, but basically leaves it at "figure it out yourself".

We now have a sample starter repo for Bridgetown plugins that folks can simply copy and roll with, so the documentation should get updated with a link to that and a simple step-by-step guide to go from downloading the code to adding new functionality to packaging it up and pushing it to Rubygems and NPM.

Motivation

If you have a lot of pages, it nice to put them under a _pages category like Jekyll does it

Suggestion

In bridgetown.config.yml, add

include: 
  - _pages

And then you can create a _pages folder within src directory where you can house all of your pages except the index page. Not sure if it's possible to put the index page within the folder as well?

It could be a good to make this the default within the framework as I think it's a good structure pattern.

Summary

Right now when you run bridgetown new mysite, a new site is created, but it does not have a README. I consider a README to be something almost everyone will add to their project, so it would be great is Bridgetown new created it for you.

Motivation

Laziness to be honest, but I think it will collectively save many time and also encourage projects to have a README, which I deem important for open source sustainability.

Guide-level explanation

• When I generate a new bridgetown site
• A standard README is included in the generated files
• The generated README should be generic, but could include helpful tidbits as well

Drawbacks

I honestly cannot think of a reason why not to add this.

Unresolved Questions

What should the README be? It could simple like rails or mildly detailed like ruby gems or it could even implement a builder to personalize for the specific project. That would be a good place to start the discussion.

This is a "mega" issue to track the ability for Bridgetown plugins to supply a manifest that can be consumed and allow files to be added to the site build from the plugin folders same as if they were in the main site folder. This would include components (aka {% render "cool_plugin/widget" %}), layouts, pages, static files, and data. A certain kind of plugin utilizing these features could be called a "theme", but there are plenty of other interesting use cases.

I already have a bunch of this working locally in a proof-of-concept branch, which is pretty neat, but I think some of the usability issues need to be thought through carefully.

• What if you want to override one of the plugin's files? I don't think "fish around in a gem repo and copy the right file" is a good answer. Maybe we need some extra CLI commands.
• What if multiple plugins try writing to the same url/data/etc. location? Should the first one win? The last one? Issue a warning?
• What if the plugin wants to adjust what it provides based on a user's configuration? For that matter, how do we handle configuration? Dump everything in bridgetown.config.yml? Use separate data files?
• What if a plugin "goes" rogue and messes up other parts of the site? How would the user know how to troubleshoot the problem? At the very least I think we'll need more debug logging that can get switched on to know exactly which plugin is doing what at which time.
• What if plugin A wants to include plugin B as a dependency? (aka "child themes", or multiple plugin "monorepos")

As benevolent dictator (😉) of Bridgetown, I'm planning on renaming the default branch name away from master. I'm open to suggestions, whether we go with main or trunk or something along those lines. main seems to be what a lot of folks are going with.

Also found this neat gist (requires latest GH CLI version) to make the switchover easy:
https://gist.github.com/mislav/5ac69530acbe1b4ca909e272caabfdba

There's no good reason not to support multiple languages and locales out of the box. So we should first document a few common use cases for what would be expected features and workflows for adding new languages (and things like date formats) to a site, and then pick the most obvious, low-hanging fruit as the first item to tackle. And the more we can make this process familiar to devs coming from other frameworks or CMSes, the better IMHO.

Also a point to remember: however this all gets implemented, it should be done in a way that makes it easy for plugins to integrate with any such enhancements. For example, what if there were a plugin that could call an API like Google Translate and provide a new language variant of a page on-demand?

As part of the work on Liquid Components in PR #26, we will be deprecating usage of the include tag and recommending a migration to render, rendercontent, and in certain cases custom tags.

The goal is to remove include entirely upon the release of Bridgetown 1.0 so we have a stable API for partials/components moving forward. FYI, this will forever break template compatibility with Jekyll…although there's no reason someone can't produce a bridgetown-includes plugin which restores the Jekyll-like functionality.

One of my biggest concerns with starting to build integrations with headless CMS APIs (Sanity, Contentful, Dato, etc.) is the likelihood of vendor lock-in. It's one of several reasons I personally gravitate towards solutions that keep content in Git as much as possible (I make a conscious exception here with regard to images, as the DX of Cloudinary for image processing is second to none).

However, there's no denying the staying power and potential upsides of the API route. One potential way we could go here to take a page out of Rails' ActiveRecord adapter strategy. In Rails, you can choose among PostgreSQL, MySQL, or a number of other database engines, and the API you actually write to stays relatively the same. They've put a lot of work into providing that level of abstraction. Sure, you can drop down to SQL and write code that only runs on PG or whatever, but that's a last resort if the higher-level APIs don't work well.

I'd like to see the same thing in Bridgetown. Define a schema of some sort and expect data to flow in a certain format, and the question of whether that data is coming from Sanity or Contentful or whatever is more of a a business decision than a technical one. It also means if you need to switch APIs in the middle of a big dev cycle, the disruption would be minimized because the Bridgetown-layer code hardly changes.

I not sure yet if this is made easier or harder in the adoption of GraphQL over REST, so that's also something we need to investigate.

Comments? Feedback? Ideas?

Our default Webpack config comes with sass-loader, partially to ease migrations from Jekyll and partially because I personally use Sass. :) But I know PostCSS is popular with a lot of folks now, so I'd like to include an example in the documentation of how to swap out Sass for PostCSS.

This isn't technically a "bug", but I find it extremely annoying that when you are developing a custom plugin in the plugins folder, changes to the code don't get picked up while running build -w or serve and you have to shut down the watcher and reload it. There's got to be a way to do a Rails-style reload automatically. 😊

I've come to discover I'm instinctually an "ActiveSupport-flavored" Rubyist, so not having all the niceties that come from ActiveSupport is a real bummer. I've already identified a number of places where both the Bridgetown internals and external plugin APIs could be improved substantially from utilizing ActiveSupport, so I think it's time to bite the bullet and get this added. I'm not sure if it will add a small amount of extra boot time, so that's something to consider, but if we're talking 100ms or less, I'm not too worried.

(Another good reason to add ActiveSupport: a major goal for this project is to find symbiotic ways for Bridgetown and Rails to work together and swim in the same developer communities, so the less friction there is for Rails folks to get up to speed with Bridgetown, the better.)

We have a monorepo with multiple gems now, but something we haven't done too much of yet is identify pieces of the core gem we can extract into a separate gem.

Filters seem to be a great place to start (and any utility methods they rely on). A few filters are very much tied to internal Bridgetown data structures, but many of them are pretty generic and can be used in any context. With a separate gem, other projects could simply require bridgetown-filters and use them without having to require any other gem in the project. For instance, Rails apps using view_component_liquid could easily make use of all these filters.

This would also be a good opportunity to identify new filters which might be useful to add. Jekyll 4.1 just added new find-* filters which seem quite helpful. (see jekyll/jekyll#8171) I'd love to see a bunch more related to ActiveSupport as well. AS is a treasure-trove of cool enhancements to core Ruby data types and the more we can bring that goodness to Liquid templates the better IMHO.

I thought it was awkward that the bridgetown new command did not create a .git repo folder. Rails does this. Can we add this functionality?

After running bridgetown new mysite and building/serving, the following error is shown in the terminal:

ERROR `/favicon.ico' not found

Might be nice to either provide a blank favicon.ico out of the box or work around this error.

Just adding a reminder here to avoid direct commits to the master branch and use proper PRs once the project really gets into full swing. At the moment it's easier for me to keep pushing like a mad man, but that's only temporary 😃

Followed the documentation to show related posts below, but the variable {{ site.related_posts }} (as well as {{ page.related_posts }}, {{ related_posts }} is always empty (Output of all {{ site.related_posts | inspect }} is nil).

Bridgetown Version:

bridgetown 0.15.0.beta3 "Overlook"

To Reproduce

• having couple of posts

<!-- _layouts/post.html -->
---
layout: default
---
   <strong>Related posts</strong>
    <ul>
      {% for post in site.related_posts %}
        <li>
          <a href='{{post.url}}'>{{post.title}}</a>
          <small>{{post.date}} &ndash; {{post.tags}}</small>
        </li>
      {% endfor %}
    </ul>

Fix/Workaround

Add , :related_posts to

Then, the variable {{ page.related_posts }} works (But not the site.related_posts according to the documentation).

If a relative file path is used for a dependency, the plugin manager doesn't recognize it and thinks the version is out of date so it tries to yarn add the package. If it's a package that hasn't been published to NPM, you see errors like this

An unexpected error occurred: "https://registry.yarnpkg.com/some-pkg-name: Not found"

It should only try to match versions if package.json is using versioned NPM packages, otherwise it should do nothing.

When running the

./compose.sh up --build

In the following repo:

https://github.com/ParamagicDev/bridgetown-plugin-tailwindcss

It returns an error for the test suite.

Bridgetown Version:

0.15.0-beta3

To Reproduce

Clone the repo.

Run :

./compose.sh up --build

Current behavior

Currently it returns a LoadError for active_support/core_ext/array/extract_options

Returns same error message as #70

Expected behavior

Expected to run without error.

Computing environment (please complete the following information):

• OS: Docker [Alpine]
• Ruby Version: 2.6.6

Additional context

The command:

bridgetown new newsite --apply="url" works without error.

bridgetown apply "url" returns an error

Motivation

Bugs

Suggestion

On the component documentation page, this link is broken:

https://github.com/bridgetownrb/bridgetown/tree/master/bridgetown-website

While we're not routinely tracking low-level Jekyll improvements at this point, occasionally something might catch my eye and this is one of them:

jekyll/jekyll#8167

Seems like something important to improve here as well.

We should integrate and demonstrate how to write integration tests that can be run in CI or during development to verify various aspects of site output, routes, components, etc. The field is wide open as far as I'm concerned as to the best way to do that. If we can stick to something simple and Ruby-based, that's cool. But I'm also willing to go for something heavy-duty like Cypress if that will better serve the ecosystem in the long run.

We have Git. We can read a site repository and understand the content in context.

Imagine a bridgetown changes command that provides a user-friendly, well-formatted list of additions, changes, and deletions in the content of the website. It would respect front matter, markdown, page permalinks, data files, etc. Also imagine this as an API which could be consumed easily by editor software. Also imagine this as something which could be attached to some sort of high-level editorial documentation, like a PR for non-nerds.

Imagine…

I don't feel like this is yet a high priority, but at some point I would like to revisit incremental generation. My primary goal would be to investigate how to detect loops on pages like blog indexes, archives, etc. so regeneration would know automatically which additional pages might need to be regenerated in addition to the one(s) that actually got updated. Yes, cache invalidation is one of the hard problem of computer science, but I believe in us! 😆

Also I'm filing this as a bug, because I think if someone's never used incremental generation and switches it on and everything seems to break (which has been my experience in the past), that's a bug!

I'm about to release 0.14.1 to fix a bug with PluginManager where it was failing during the yarn add process if package.json was missing the dependencies key. 😬

Summary

I'm currently reviewing Bridgetown's plugins/hooks system and iterating towards an out-of-the-box solution for external API data import starting with REST-style calls. That let me to review what, if anything, we're currently using for an HTTP client. Currently there are some serve commands that seem to use the httpclient gem, so that's a good place to start refactoring.

Motivation

My ultimate goal is to allow folks to write tiny plugins (aka barely more than a one-liner in many cases) that will automatically provide data from external APIs to the site build (pages, templates, etc., so it's important that Bridgetown come with an opinionated default of an HTTP client plugins can standardize on. And for a variety of reasons (not least of which it's part of the standard Rails bundle), Faraday seems top of the list. The API for instantiating connections can get rather verbose, but we can easily built a thin wrapper around that which will be sufficient for "most" use cases.

Related to #77, currently we're assuming that if a branch name isn't specified for an automation via a GitHub URL, then look for the automation script in the master branch. Fair assumption.

But we really should be looking at the default branch whatever it is, whether it's main or something else. I'm not sure if there's an easily-accessible API of some kind to ask GH what the default branch name is for a given repo. Barring that, I'm thinking we'll just need to try both main and master and pick the first one that doesn't 404. If you have ideas for how to do this cleanly, please let me know!

There's something odd going on with our use of Swup.js the transition to/from the docs section vs the rest of the site (blog, homepage, etc.). It goes to the new layout just fine, but if you hit the back button, you get redirected back to the current page again instead of actually going back. Not yet sure if this is something funky deep in the guts of Swup or I just set up something wrong.

By far the messiest code pattern I've seen while working on Liquid components and templates in general is constructing a string of CSS class names based on incoming variables. Typically in frontend component libraries you'll see a "class map" function that makes this process pretty straightforward. Prior art:

• https://lit-html.polymer-project.org/guide/styling-templates
• https://github.com/JedWatson/classnames

It would be great to have a Liquid tag to make this easy. Something like:

<button class="{% class_map is-small: small, has-text-center: centered, outlined: !filled %}">…</button>

We'd have to do some fancy parsing to load variables from local scope and work with conditional values, but the actual business of constructing the output string should be pretty easy.

I'm also tempted to make this its own little gem so it can be used anywhere, but maybe we can implement here first and extract it out at some point once it's working well.

As a potential deployment strategy, or a development strategy for that matter, we should document how to use Docker and Docker Compose to spin up a Bridgetown dev server and also how to build a production site and serve via, say, Nginx.

We might even consider creating an official Docker Hub image for Bridgetown and deploying that as part of our standard release process (but that should probably be filed as a separate issue).

When document hooks are triggered, both hooks under the collection name (whether posts or something else) and a generic hook under documents are triggered at the same time, but there's no mention of the in the documentation. It talks about posts hooks and documents hooks, but the posts hooks aren't really a separate thing…that's just a by-product of posts being in a collection called posts. You could also code for tutorials hooks and events hooks and whatever else you want. So we should update the documentation to reflect that.

Summary

I am not sure if this should be under docs or feature, but in jekyll, I can set up a _redirects file.

Is it fine to do that in bridgetown? if yes, it might be worthwhile to add a page in the docs

It'd be great to have a defined collection of plugins we can add and update in the website repo and accept PRs for when folks create new plugins. Title, GitHub link, description, maybe tags, etc.

Currently Rubocop is configured to ignore class lengths > 240 lines for the following files:

• document.rb
• site.rb
• commands/serve.rb
• configuration.rb

It should come as no surprise that I hate every time I have to wade into one of those files. :)

Definitely need to refactor those into multiple concerns and/or supporting POROs, starting with Site.