Remove print extension uniqueness validation
WHY are these changes introduced?
Remove print extension validation which should live in Core. issue #1183
NOTE: This shouldn't be merged until core validation is merged in this PR
WHAT is this pull request doing?
Remove the validation as it is implemented in cor in this PR
How to test your changes?
- Create an app with two print extensions with the same target
- In the CLI project, checkout the branch
1183-move-cli-validation-to-core - In an spin instance, go to shopify shell and checkout the branch
1183-move-cli-validation-to-core - Try to deploy the app using the local CLI branch, it should return an error mensioning the extension handles and the target
Measuring impact
How do we know this change was effective? Please choose one:
- [x] n/a - this doesn't need measurement, e.g. a linting rule or a bug-fix
- [ ] Existing analytics will cater for this addition
- [ ] PR includes analytics changes to measure impact
Checklist
- [x] I've considered possible cross-platform impacts (Mac, Linux, Windows)
- [x] I've considered possible documentation changes
Thanks for your contribution!
Depending on what you are working on, you may want to request a review from a Shopify team:
- Themes: @shopify/advanced-edits
- UI extensions: @shopify/ui-extensions-cli
- Checkout UI extensions: @shopify/checkout-ui-extensions-api-stewardship
- Hydrogen: @shopify/hydrogen
- Other: @shopify/app-management
Coverage report
St.:grey_question: |
Category | Percentage | Covered / Total |
|---|---|---|---|
| π‘ | Statements | 72.42% (+0.07% πΌ) |
7797/10767 |
| π‘ | Branches | 69.4% (+0.03% πΌ) |
3844/5539 |
| π‘ | Functions | 71.23% (-0.04% π») |
2052/2881 |
| π‘ | Lines | 72.72% (+0.08% πΌ) |
7364/10127 |
Show files with reduced coverage π»
St.:grey_question: |
File | Statements | Branches | Functions | Lines |
|---|---|---|---|---|---|
| π’ | ... / loader.ts |
94.08% (-0.27% π») |
85.88% (-0.32% π») |
97.85% (-0.15% π») |
95.18% (-0.19% π») |
Test suite run success
1787 tests passing in 813 suites.
Report generated by π§ͺjest coverage report action from a3be9388d306802db54ae836ba18fa5b5482e8ef
We detected some changes at either packages/*/src or packages/cli-kit/assets/cli-ruby/** and there are no updates in the .changeset. If the changes are user-facing, run "pnpm changeset add" to track your changes and include them in the next release CHANGELOG.
/snapit
π«°β¨ Thanks @alfonso-noriega! Your snapshot has been published to npm.
Test the snapshot by intalling your package globally:
pnpm i -g @shopify/[email protected]
After installing, validate the version by running just
shopifyin your terminal If the versions don't match, you might have multiple global instances installed. Usewhich shopifyto find out which one you are running and uninstall it.
...it would mean they can still dev an app with duplicated print targets even if the backend validation fails. Should we actually be failing the dev process when an error happens when attempting to update the extension version?...
@vividviolet,this won't be an issue anymore once the new consistent dev and dev dashboard projects land as they will create a version on dev?
That's correct.
@vividviolet, what would happen if you dev with duplicated print targets? would the draft update fail? where will it eventually crash?
this won't be an issue anymore once the new consistent dev and dev dashboard projects land as they will create a version on
dev?
@alfonso-noriega It wouldn't be an issue in production but still an issue in development.
@vividviolet, what would happen if you
devwith duplicated print targets? would the draft update fail?
When you dev with duplicated target the draft update will fail and show and error in the logs. However, the dev process isn't stopped so you can still dev. What I'm suggesting is for us to just fail on validation errors instead of letting them go through with dev using a "broken" extension.
where will it eventually crash?
It doesn't really crash currently because there's extra logic in Web to account for multiple print action extension (I believe we just use the first one). I would like to get rid of the extra logic if possible. We have extra logic for when the name is not populated as well even though it would fail validation.
What I'm suggesting is for us to just fail on validation errors instead of letting them go through with dev using a "broken" extension.
I think it makes sense to stop dev if there is an error in the draft upload.
I think it makes sense to stop dev if there is an error in the draft upload.
@isaacroldan should we take an action on this? I can extend this PR to fail on draft upload error or create a new one. But we should not merge this one until we get that merged.
What I'm suggesting is for us to just fail on validation errors instead of letting them go through with dev using a "broken" extension.
I think it makes sense to stop
devif there is an error in the draft upload.
FYI, here's what happens on a validation error currently. The dev process just continues:
cc @alfonso-noriega @cameronbarker
This PR seems inactive. If it's still relevant, please add a comment saying so. Otherwise, take no action. β If there's no activity within a week, then a bot will automatically close this. Thanks for helping to improve Shopify's dev tooling and experience.