Rationalize exported crawlSpecs function behavior #1812
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The exported
crawlSpecs
function has always behaved differently depending on whether the first parameter it receives is an array of specs, or an object that sets crawl options. Some of these differences are more historical artefacts than anything else, did not make any sense, and could bite ;) (for example, in browser-specs, I cannot access the markdown summaries that were added by the previous release of Reffy, because they are only reported to the console...)This makes a minimal amount of updates to rationalize the behavior of the function (which maps internally to
crawlList
andcrawlSpecs
). In particular:crawlList
now accepts getting specs shortnames, series shortnames or URLs as input, same format ascrawlSpecs
in short.crawlList
now also processes thesummary
option to add markdown crawl summaries to each spec, as done bycrawlSpecs
.crawlSpecs
now accepts a specific{return}
value for theoutput
option that makes it return the index of crawl results to the caller and not output anything to console and files (the function could only report to the console or to files, and there was no way for a caller to access crawl results). If post-processing modules need to run at thecrawl
level, their results are now reported in apost
property.Differences that remain are:
crawl
level. That's also somewhat logical as there would be no way to report the results in the returned array.{return}
value (remains clunky but) goes in the other direction and forces the function to return an index of crawl results so that a caller may process further things.Changes should be non-breaking.