* Validate input to BadgeFactory.create() (#3875)
* validate input to create()
* remove deprecated properties (#3881)
* remove BadgeFactory class (#3884)
* Template literal templates (#4459)
- Remove use of the doT template library and move to generating SVG output using javascript template literals.
- Drop SVGO and mostly manually implement the optimisations.
- Add a bunch more tests
Co-authored-by: Paul Melnikow <github@paulmelnikow.com>
* drop raster support in package CLI (#4523)
* drop raster support in package CLI
* update docs
* rename gh-badges package to badge-maker
* rename gh-badges dir to badge-maker
* update relative imports and other refs to in parent dir
'gh-badges' --> 'badge-maker'
* update snyk service tests
This change is only tangentially related
We've used the shields repo as an example for these tests so
moving files around in our repo has a knock-on effect on them
* add missing type hints to dev style page
* write the changelog/migration guide for v3
* use extension in README CLI example
* update CLI help
whoops - missed this in #4523
* bump version
* update for self-hosting users
* README updates
* drop .format param from CLI, always output SVG
* Change text[] to label and message, Remove JSON output
- Change text[] to label and message
- Fix message only badge
- Remove JSON output format
- Update the docs
* update package-lock
* rename 'template' to 'style'
* handle invalid styles in coalesceBadge
* ensure makeBadge is passed a string for template in coalesceBadge()
issue #4925
* fix (logo/no label text/label color specified) case
issue #4926
* add example of (logo/no label text/label color specified) to style debug page
* update type defs
* padding fix for FTB style
Co-authored-by: Paul Melnikow <github@paulmelnikow.com>
It can be helpful to have some diagnostic pages for development and quality control. I added one here for the logos, which renders all the named logos in ?style=flat and ?style=social.
While Next.js can handle static sites, we've had a few issues with it, notably a performance hit at runtime and some bugginess around routing and SSR. Gatsby being fully intended for high-performance static sites makes it a great technical fit for the Shields frontend. The `createPages()` API should be a really nice way to add a page for each service family, for example.
This migrates the frontend from Next.js to Gatsby. Gatsby is a powerful tool, which has a bit of downside as there's a lot to dig through. Overall I found configuration easier than Next.js. There are a lot of plugins and for the most part they worked out of the box. The documentation is good.
Links are cleaner now: there is no #. This will break old links though perhaps we could add some redirection to help with that. The only one I’m really concerned about `/#/endpoint`. I’m not sure if folks are deep-linking to the category pages.
There are a lot of enhancements we could add, in order to speed up the site even more. In particular we could think about inlining the SVGs rather than making separate requests for each one.
While Gatsby recommends GraphQL, it's not required. To keep things simple and reduce the learning curve, I did not use it here.
Close#1943Fix#2837Fix#2616
