Shubh: "I was asking which markup syntax" - CommonMark to begin with, possibly a MeB flavour markdown later down the road. I thought I had already answered this question in my comment on the ticket. :) Allowing full HTML is way overkill and also a security nightmare and also not very user friendly.
Shubh
Freso: agreed
KassOtsimine
mb does also not allow direct html
MRiddickW joined the channel
BenOckmore
monkey: Updated the BS4 prep PR with a few more commits, it's ready to go now, but I think there might be a testing infrastructure issue with the lint check: https://github.com/metabrainz/bookbrainz-site/p...
monkey
Yep :) Was just in the process of writing a comment on that
BenOckmore
The actual bootstrap 4 PR is also ready to be opened but I'm just getting a few things checked into my local lobes repo
monkey
So it looks like we can't auto-fix lint issues and commit those changes in a PR if the PR is from a forked repo (and trying to make it work would be unsafe, says Github).
So instead I set it up to do two things: 1. on push commits on the master branch (that should include merging PRs), we run the linter and auto-fix issues.
Yes, so running ESLint when rebuilding webpack only gives marginal benefits compared to manual linting, but doubles the build time. We could make it so that ESLint runs pre-commit or just before webpack starts as alternatives, and/or the auto linting on PR merges
And yeah, eslint-webpack-plugin would also need removing from package.json, I missed that!
monkey
OK, thanks for the explanation. That works for me; let's keep the eslint webpack plugin for now and I'l see what method works best for us.
MRiddickW has quit
I could see a scenario where we would want to lint and autofix during production builds, so the plugin might be useful after all.