feat(schemas): extend schema and split builders

[kaltepeter]

fixes: #9

• split builder by conversionType
• adjust schema to support all types

I had originally intended to create a separate schema for each type but that introduced a few challenges. The builders are able to stay isolated easy enough.

Schema options/challenges:

• separate schema for each builder and duplicate the definitions of baseOptions, a bit painful to maintain if changing base options
• separate schema using $ref to include base options for that schema. Did not work with angular cli requiring explicit uri's for refs. Tested with gist and it would work if the uri exists. (https://json-schema.org/understanding-json-schema/structuring.html#extending)
• Where i landed: using conversionType to conditionally include the properties for a builder using the $ref technique in the same schema file. (https://json-schema.org/understanding-json-schema/reference/conditionals.html)

Things to consider:

• I removed the required fields from base options that have defaults assigned to avoid having to define all base options that have a sensible default. e.g. If this field is in required properties of the schema the user has to still add to every builder config in angular.json

 "srcFiles": {
          "type": "array",
          "description": "Input files matching the given filename pattern.",
          "items": [
            {
              "type": "string"
            }
          ],
          "default": "['*.svg']"
        },

This approach can be take further or require the builder config to provide all required fields and make it easier with #15 generating the default config. @kreuzerk I stopped here as a good point to get thoughts. Maybe issue #15 is a better place to decide.

[kaltepeter]

I remove the check for options.conversionType because schema now requires it and it won't get to the error.
I added a check to match builder with the options.conversionType and removed extra conditionals to simplify.

[nivekcode]

Perfect - that's also how I imagined it.

[nivekcode]

With the comment above I think that we can also remove this check. Basically, we would remove the conversionType from the options in this project.

[kaltepeter]

Gave this a shot and it raises a question. It's trivial to remove the validation bit in the index.ts files. The side effect is I can't remove the requirement from schema.json because that drives the conditional logic and schema checks run before any typescript checks, otherwise I could just for the correct value on the typescript side.

Removing validation would be ok, maybe, because in an ideal world the ng-add setup the builder correctly and it should work. Other fields would also likely fail if the user mismatched them, just not sure they would know why.

Thoughts on this?

[nivekcode]

I see. Very good point. I didn't think about this. In this case, I would leave it as it is. Maybe it's even better because then the options are the same as in svg-to-ts

[nivekcode]

@kaltepeter very very nice, well done 👍 The only thing I would still do before merging is to remove the conversionOption from the schema and the README. What do you think?

After we merged this, I think we are ready to release v1.0.0. The ng-add can then be another feature that follows later, what do you think?

[nivekcode]

Do we still need to specify the conversionType? I think this is already specified with the builder.

[nivekcode]

With the comment above I think that we can also remove this check. Basically, we would remove the conversionType from the options in this project.

[nivekcode]

Very cool - I didn't know that you can use if then statements in schema.json

[kaltepeter]

I didn't either! I was trying to re-use fields and found this. The nice tool online to test schemas does not yet support this but working in small bits worked.

[nivekcode]

This is also something we should export from svg-to-ts. I will do this and then adjust later once a new version from svg-to-ts is deployed.

[kaltepeter]

Sounds good!

[nivekcode]

🎉 This PR is included in version 1.0.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀