Build sb-admin ourselves for customization

[mkasberg]

This is an alternative approach to #123. The high-level approach is the same: Include some development tooling from NPM to build styles, and commit the built styles to this repository to serve in production. The difference is that in this PR, I'm continuing to use the sb-admin theme and Bootstrap. This will allow us to work incrementally to tweak the theme to our needs rather than overhauling everything. We can still pursue some cleanup such as tweaking cards, changing colors, or consolidating the navbar, but we can do so incrementally in smaller steps (in later PRs).

For the most part, our build tools match those in sb-admin. The difference is that I've ripped out stuff we don't need (pug, scripts, etc) and I've added some things to run PHP via npm start (so a single command can run everything for local dev).

The scss folder is a verbatim copy of the scss from sb-admin.

The scripts folder is based on sb-admin but includes light customization (for our file locations, etc).

[JohnRDOrazio]

The only thing I dislike about checking in external code into the repository, is that it's harder to keep the repo clean and orderly with certain conventions. If there are updates from external repositories that need to be checked in, then the code that is pulled in from outside would need to be reformatted and cleaned up if we want it to get a good "score" with for example CodeFactor. I'd say I've made my own code so much better by implementing CodeFactor, following as many suggestions as possible to make the code readable and follow standards; however every external repo that you check-in will probably not follow the same standards and will cause a lower CodeFactor score.

Do you think a possibility could be to simply fork the sb-admin repository, work on the fork in it's own repository, and then either pull in the results in package.json and a build step OR simply continue as we are now, linking directly to the script and css from a cdn... This last option I don't think is all that bad, it avoids any hassle with build steps and keeps the current repo as clean as possible...

[JohnRDOrazio]

In any case I'm noticing at least one difference in the public facing results compared to the current development branch: the ol.carousel-indicators and child lis don't have list-style: none set and so we have numbers showing up next to the carousel indicators.

[JohnRDOrazio]

Do you think a possibility could be to simply fork the sb-admin repository, work on the fork in it's own repository, and then either pull in the results in package.json and a build step OR simply continue as we are now, linking directly to the script and css from a cdn...

I also think that this option would mean making the work on the fork available for the general public: if anyone else wanted for example the "blue" theme back again, we would be offering a service useful not only for a single repository, but for anyone who wanted the blue theme. And we might even find a few things to fix while working at it, which could be pulled back upstream in the main theme repository.

[mkasberg]

If there are updates from external repositories that need to be checked in, then the code that is pulled in from outside would need to be reformatted and cleaned up if we want it to get a good "score" with for example CodeFactor.

I'm proposing that there are never any "updates" to this "external" code. If we move forward with this draft PR, we'd start treating it as a template rather than a dependency.

I didn't format it yet as this is only a draft, but I'd be happy to make any new code match your CodeFactor settings if we want to move forward with this approach.

Do you think a possibility could be to simply fork the sb-admin repository, work on the fork in it's own repository, and then either pull in the results in package.json and a build step OR simply continue as we are now, linking directly to the script and css from a cdn... This last option I don't think is all that bad, it avoids any hassle with build steps and keeps the current repo as clean as possible...

Yes, I do think this would work. It wasn't my preferred approach because I'd prefer to have the scss in the same repo as the code. But if you prefer the separate repo, I could make that work. If you want to pursue this, could you create a fork of sb-admin owned by @Liturgical-Calendar? I don't have permission to do so.

[JohnRDOrazio]

I created a fork with a new branch blue-theme, as a way of working at bringing the blue theme back again. Then if there are any other ideas / approaches we can always create other branches to work on. And maybe even send a PR back to the upstream repo if it's anything that could be useful for the general public. https://github.com/Liturgical-Calendar/startbootstrap-sb-admin/tree/blue-theme