Other Odds and Ends

Testing Modules

One useful trick is to copy the source code for a high-level HTML page into an unsaved separate file. Then refactor a module, or many of them. Update the high-level page and compare it with the copy, using BBEdit’s compare two front windows tool. If the files are identical, then nothing you’ve done has broken the module for that page. If the files aren’t, you can see what needs to be fixed.

Similarly, if you’re using Git on a committed repo, you can update the entire site and then use git status to see if any files have changed.

This approach provides confidence that refactoring a module hasn’t broken the website.

Searching Modules

Navigating through the modules and their internal files can sometimes be a pain. Perhaps all you want to do is change a string somewhere and you don’t want to have to follow the chain of includes in order to find it. BBEdit provides a very good search and replace feature which can be limited to just search the modules folder. I also particularly like “The Silver Searcher” (GitHub) based on “ack”. It is invoked on the command line using ag — e.g. ag '#COMPANY#' to find a variable or ag -i 'click button to continue' to find a case-insensitive string. (Quotes can be eliminated for simple strings with no spaces.)

Start in the app/modules/ root to speed up the search. Ag returns the relative path of the file containing the string together with the line containing it. I often scrape and copy that path and then, still in the terminal, open that file in BBEdit and adjust the target string: bbedit markup/social/items/twitter.shtml.

Modules are Reusable

While the data for each website is unique, often a module can be modified for reuse on another site. If a reused module manages the social media links, for example, the links themselves (items/), the markup (types/), and the order (lists/) will have to be changed, but those changes are quite easy once the new markup structure is known.

If a module depends upon another module — it calls it — then reusability gets more complex. The promise of the called module needs to be satisfied in the new website.

Also, modules often use variables declared in the Page module’s entry.shtml file. Those variables need to be carried over from one site to another. If a particular variable has not been defined, BBEdit just keeps the variable name itself — i.e. #COMPANY#. When you see the string #COMPANY# on your web page, it’s pretty clear what caused the error.

Modules are Build System Agnostic

Of course, Code Modules work fine with an all BBEdit workflow. But Code Modules also works well with sites built using Grunt or Gulp. The Sample Website uses Parcel to build the site. I’ve used Code Modules successfully in Gatsby projects packaged using Webpack. Code Modules doesn’t care about how the site is built so long as you can use BBEdit’s update feature to add the output of includes to the top level HTML files or the source used to build those files.

BBEdit has outstanding Applescript support. Should you wish, you can use Applescript together with your code runner to create a build process that will automatically update your BBEdit includes across the site at build time.