Resolve Rubocop offenses

[neilvanbeinum]

Reviewers - let me know if you want these squashed down to a single commit.

[andrewmcodes]

Thanks for making this PR! I like the rule change to eliminate unnecessary escapes but it appears that some of these changes are unsafe and have changed the output of these bundled configurations.

Unless @jaredcwhite objects, I would disable this rule for the bridgetown-core/lib/bridgetown-core/configurations/**/*.rb folder.

I also personally like to squash these but it can be squashed on merge so I'll leave that up to you.

[jaredcwhite]

@andrewmcodes @vvveebs I agree, I would like to avoid changing anything that ends up as output in user projects at the present moment.

[neilvanbeinum]

Thanks both.

I remember having some fun with the config files and their output when I made this :)

I believe there are a few little edge case bugs which I was attempting to fix here rather than add an overarching Rubocop ignore rule but I probably didn't do a great job of explaining where I was coming from.

If I don't hear from folks in the coming days, I'll make a dedicated issue and add an ignore rule so we can move on :)

Essentially I think we are ending up creating a couple of regexes which contain the "any character" character class (.) rather than the period character (\.) and I think we want the latter.

It's best to give an example in JS. Taking the example of the post CSS filter regex:

> const mainBranchLitRegex = /(?:index|.global)\.css$/  // this is a regex extracted from esbuild.config.js if you run `bin/bridgetown config lit` on main branch

> "somethingglobal.css".match(mainBranchLitRegex)  // the [docs](https://www.bridgetownrb.com/docs/components/lit#sidecar-css-files) say the expected suffix is '.global.css' but this string matches despite not having that suffix

A similar pattern seems to be in the stimulus config which modifies controller filenames. I doubt anyone has been stung by these edge cases but I figured best to try to fix them (with an additional escape \) if it means we can avoid a Rubocop ignore rule in case that ends up hiding something lurking for us in the future.

[jaredcwhite]

Essentially I think we are ending up creating a couple of regexes which contain the "any character" character class (.) rather than the period character (.) and I think we want the latter.

Daaaang… @vvveebs you're right! After trying this out manually, turns out in a heredoc we have some odd escaping gotchas just like in regular strings. So in that JS heredoc, \. ends up just . which isn't what we want! So I'd say yes, we should take Rubocop at its word on this and add the additional escaping. cc @andrewmcodes

[andrewmcodes]

@vvveebs well TIL 😅

[andrewmcodes]

If these are correct as @jaredcwhite mentioned than this is good to go from my perspective! Thanks @vvveebs!

[neilvanbeinum]

Thanks folks.

I realised that there were some more steps to get the build reinstated. Think they have been ticked off now hopefully - learnt some things along the way.

Here's the latest on this PR:

• Most Rubocop updates squashed into one commit.
• Note I have gone ahead and added a Rubocop exclude for Collection.rb ClassLength. It's just nudged over our limit - I had a quick look but couldnt' see any obvious routes for refactoring.
• Additional commits for a few test fixes to reinstate the build. I've added a bit more context in the commit messages.

[jaredcwhite]

Thanks for getting this over the edge @vvveebs. 🙏🏻 There might be a couple more things to massage here or there but probably makes sense to do that as new PRs off of main. Merging!