Break source code into modules#28
Conversation
RafaelGSS
left a comment
There was a problem hiding this comment.
What's the reasoning behind this change?
To be honest, I don't see this package adopting TypeScript for any reason (as I said in #24)
If the idea was to make the core clearer, that's reasonable. Although, I feel this is a bit of overengineering for a quite simple project.
Ease of maintenance, like ability to add unit tests. Only the files being edited will be changed in future PRs.
Adopting TypeScript was just an example, as there are multiple functions. We don't need to adopt it, and continue using equivalent, like JSDoc. |
|
Moving to draft, as this might break GitHub Action which expects json and etag files in root folder. |
|
Replaced by a subset in #29 |
This PR attempts to breaks source code into modules.
While breaking the source code, I merged the duplicate code in
eol-versionsandisNodeEOL.I also checked in the contents of content and etag files for schedule and security. This will reduce
GETcalls when etag is latest and is verified usingHEADcalls. We can also set up recurring GitHub workflow to update the contents of cache.This will also allow migrating to TypeScript in future, and either transpiling or type stripping using amaro depending on what maintainers think. It will also allow adding unit tests using Node.js Test Runner for individual components.