Build: regex-based <g> insertion matching svg tag, to be more reliable

[folletto]

The previous svg-transform-add-g grunt task used a blind match on the string, relying on viewBox="0 0 24 24"> to be at the end of the <svg> tag.

This PR updates the script to use a RegEx matching the <svg> tag in a more generic way:

• Start: <svg[^>]*> (matches anything inside the svg tag that is not a >, then gets the > as the ending of the tag)
• End: </svg> (escaping the /)

This bug was found during testing of #256.

To test

1. Delete /svg-min folder
2. Run grunt
3. Make sure no SVG that has been re-generated has any change (there should be any changed file in the git tracking)

[gwwar]

Have we looked into converting the other transforms to use xml2js over regexes?

See example in svg-transform-to-camelcase.js I believe we should be able to manipulate the intermediate object format result in the callback, before building the file output again. This should be less error prone in general than trying to get a regex just right with xml.

[folletto]

Have we looked into converting the other transforms to use xml2js over regexes?

I agree! ...and that's tracked in #123.

I didn't have time yet to do it — This was meant as a quick fix for the problem as currently it's blocking a PR to get in, and I couldn't see any easy code in the svg-transform-to-camelcase.js to do it as quickly as I did this PR.

If you think it's good enough — even if I agree not ideal — let's merge this first. If not, I can try to find some time to look into #123. :)

[gwwar]

Oh nice that we have that tracked. I'll try and take this for a spin later. Also summoning @dmsnell since we used the word regex here.

[dmsnell]

if we run this twice, won't get we <g><g>?

although what @gwwar brought up is 2000% relevant here, that non-RegEx-based parsers are quite important here, for a quick implementation we can find only those <svg things that aren't followed by <g things

const svgWithoutG = [
	// (?:<svg)     - find the opening prefix (non-capture)
	// ([^>]*)      - capture any tag-internal content
	// (?:>(?!<g>)) - followed by a closing `>` which is not also followed by a `<g>`
	/(?:<svg)([^>]*)(?:>(?!<g>))/,
	'<svg\1><g>'
];

const _svgWithoutG = [
	// grab even those with a closing `</g>`
	// then normalize the endings so they all have it
	/(?:(<\/g>)?<\/svg>)/,
	'</g></svg>'
];

Note that what this won't do is handle nesting - if we have nested <g> groups we'll likely mess them up.

[folletto]

if we run this twice, won't get we <g><g>?

Not a problem: this is always run only on a re-generated file for safety.

I'd rather keep the simpler form, but nice use of lookahead there, and I didn't know there was a way in JS' runtime to do non-capture. TIL!

[dmsnell]

I meant that when we regenerate the files again the current RegExps will double the group element.

I'd rather keep the simpler form

sure, but neither one is really complicated… the given ones are just a little misleading because of how they leave out the <g> part

[folletto]

We discussed in private with Dennis as there was some misunderstanding on how this was generated / regenerated.

To explain this more extensively: the files are generated every time from the source, so there's no instance where the <g> could happen to be added twice as the file the script works on is always new.