[v2] release prep

[hardy613]

Description
Preparation for v2 release.

For reference the full changelog for v2 is:

• breaking remove JSONArray for JSONValue[]
• breaking fromJSON only accepts JSONValue
• breaking fix [BUG] - Using strategies on Array types runs the strategy on array elements instead of the whole array #125 strategies are now passed the full array, this allows more
  flexibility for conversions
• breaking removes array as a strategy, use composeStrategy instead
• move docs/ to README.md and delete folder
• fixes Convert all sub functions to arrow functions  #135
• fixes [BUG] - Clone #134
• std@0.129.0
• public strategies are all functions to be run to get the runtime function
  iso8601Date => iso8601Date()
• deno@1.19.x
• fmt with deno@1.19.x
• turn off unstable code coverage
• add type guard in getNewSerializable fixing compile issue
• fix [BUG] - run deno lint --unstable  #121 address lint issues
• add fromSerializable strategy
• fix Add clone functionality #132 adding serializable.clone(json: JSONObject): this

Once merged we'll need to update the changelog once more with the release date

Things to look at

• Test coverage
• Code Style
• Documentation (README.md, CHANGELOG.md, etc..)

[ChrisDufourMB]

LGTM!

No blockers, just a few comments.

[ChrisDufourMB]

I think the original reason we did this was to that in exceptions we would get a named function to show up. I have no strong opinion one way or the other though.

[hardy613]

yeap. @ms1111 mentioned this as well and initially, that was the idea, however, the parent function will display in the stack trace which will lead developers to the right location. There are other benefits as well, we are not creating a new object prototype, which also means it cannot be newed and a new function scope is not created.

I think it makes sense that we go with: For global scope, we can use function, for new constructors we can use class and for everything else we can use () => {} .

[ChrisDufourMB]

What's the reasoning behind this change? In addition to the CI aspect I thought that the node tests were also a code example of how you can use ts_serialize in a typescript context, so it made sense to have them as part of the docs.

On the other hand node usage is covered in the README, so I'm fine with this change

[hardy613]

basically from conversations, it was trying to be both examples and tests, but not doing a good job of either. This move is to remove it from the root so the docs/README is used. With the changes to the readme now this is only used on github so it made sense to move the folder.

TBH, the deno -> node conversation has probably moved forward from when we last looked and there might exist a solution that allows us to run the deno tests within a node env.

[ChrisDufourMB]

Sounds good, I will create a discussion to see if we can find a better way to transpiling into node