GScan 2.0 should be able to scan a 1.0 theme #116

kirrg001 · 2018-07-17T22:56:25Z

GScan 2.0 should be able to:

scan a theme for Ghost 2.0 (latest)
scan a theme for Ghost 1.0 with the help of a flag e.g. gscan --v1

The idea is that GScan is able to scan a "new" and a "previous" version of Ghost.
If we e.g. ship Ghost 3.0, GScan will scan latest (3.0) and 2.0.

GScan must provide a ruleset for both versions. Currently we are making use of a single spec.js file, which holds most of the rules. Some of the rules live inside the checkers, which should be moved into the spec.js file.

Which rules to apply on a 2.0 theme?

I think we have to apply all rules from 2.0 and 1.0 🤔 We just need to ensure that the GScan 2.0 branch doesn't have a rule, which conflicts for 1.0 and 2.0. Theoretical example: We have a deprecation rule in 1.0, which tells the user to use Y instead of X. And in 2.0 we tell the user to remove Y completely, because it's no longer supported. GScan should not show both warnings/errors.

Tasks

make it possible to pass a version argument --v1, which will tell GScan to scan the theme based on Ghost 1.0 rules
add a very simple UI to choose latest or v1
merge into GScan 2.0 branch
output scanned version (see comment here -> Output the major version that was checked #128
Write logic to remove rules in a newer version (e. g. a prev. known helper should now be removed), see comment here
Central place to adjust the major version (similar to a config value) -> Use util to handle versions and update doc links #127
Make links to documentation dependent on the version (see comment here) -> Use util to handle versions and update doc links #127

The text was updated successfully, but these errors were encountered:

refs #116 - Added `-v1, --check-version-1` option to allow cli usage of GScan to check for 1.0 theme compatibility - Pass `options` that includes a `checkVersion` property, which is set to `1.0` when cli called with `-v1`, or `2.0` by default.

refs #116 - create a new `/specs` directory - rename current `spec.js` to `001.js`

refs #116 - Offer a select box with the - currently - two accepted versions, whereas the latest is set to default - Pass the selected version to gscan

closes #116 - CLI - Added `-1, --v1` option to allow cli usage of GScan to check for 1.0 theme compatibility - Passed `options` that includes a `checkVersion` property, which is set to `v1` when cli called with `-1`, or `latest` by default. - Restructure current specs - created a new `/specs` directory - renamed current `spec.js` to `v1.js` - duplicated current `spec.js` to `latest.js` -> will contain only differences later - the latest version will inherit the ruleset from `v1`, but overwrite properties that exist in both - App - Offered a select box with the - currently - two accepted versions, whereas the latest is set to default - Passed the selected version to gscan - Checks - moveed checks properties (regex, helpername, cssclass) to the rules in spec - useed list of rules to specify which rules have to run for each version (concat them, if applicable) - require the version of the spec that we need for the checks only

aileen · 2018-08-08T02:44:30Z

I closed the opened PR #118 and updated the tasks in the original comment here to keep track of what's left to.

refs TryGhost#116 - Added a util with a version file, that can take properties and handle `latest` versions and other versions in a more gneric way - Added functionality that replaces old document links with the new ones, based on the `latest` version number.

refs TryGhost#116 needs TryGhost#127 - uses the versions util to fetch the major version and pass it along our `theme` object - outputs the tested version for CLI and App usage - for module usage, GScan returns a `checkedVersion` property with the major version that it was checked for

kirrg001 · 2018-08-08T08:24:28Z

I can still find some https://themes.ghost.org/v1.25.0 links in the GScan 2.0 branch.

aileen · 2018-08-08T08:25:31Z

I can still find some https://themes.ghost.org/v1.25.0 links in the GScan 2.0 branch.

See #127

aileen · 2018-08-08T08:29:53Z

I updated the tasks with the PRs where I fixed it

refs TryGhost#116 - Added a util with a version file, that can take properties and handle `latest` versions and other versions in a more gneric way - Added functionality that replaces old document links with the new ones, based on the `latest` version number.

refs #116 - Added a util with a version file, that can take properties and handle `latest` versions and other versions in a more gneric way - Added functionality that replaces old document links with the new ones, based on the `latest` version number.

refs TryGhost#116 needs TryGhost#127 - uses the versions util to fetch the major version and pass it along our `theme` object - outputs the tested version for CLI and App usage - for module usage, GScan returns a `checkedVersion` property with the major version that it was checked for

refs TryGhost#116 needs TryGhost#127 - uses the versions util to fetch the major version and pass it along our `theme` object - outputs the tested version for CLI and App usage - for module usage, GScan returns a `checkedVersion` property with the major version that it was checked for - updated README to include version usage

refs #116 - uses the versions util to fetch the major version and pass it along our `theme` object - outputs the tested version for CLI and App usage - for module usage, GScan returns a `checkedVersion` property with the major version that it was checked for - updated README to include version usage

kirrg001 · 2018-08-11T12:07:31Z

@AileenCGN I would suggest to raise a new issue and describe:

Write logic to remove rules in a newer version (e. g. a prev. known helper should now be removed), see comment here

Because this issue is specific to GScan 2.0.
Then we can close this issue.

aileen · 2018-08-12T02:31:31Z

@kirrg001 Sure thing. Have a have ready local solution for it already, but let's close this one in favour of #135

This issue was fixed with 9d5603c and ba6b511