Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implemented no-amplify-errors in packages where it should be active #1973

Merged
merged 7 commits into from
Sep 10, 2024

Conversation

ShadowCat567
Copy link
Contributor

@ShadowCat567 ShadowCat567 commented Sep 9, 2024

Problem

no-amplify-errors should be active in more packages than just auth-construct
Issue number, if available: N/A

Changes

Implemented no-amplify-errors lint rule in most packages where it should be active.
Only packages that are excluded which will eventually have no-amplify-errors activated in are platform-core and client-config -- has too many errors to be included in this PR.
model-generator and schema-generator had some violations, but all their violations seem to be fine to leave as AmplifyUserError (added in line ignores for them).

Corresponding docs PR, if applicable:

Validation

linter is happy with the updates

Checklist

  • If this PR includes a functional change to the runtime behavior of the code, I have added or updated automated test coverage for this change.
  • If this PR requires a change to the Project Architecture README, I have included that update in this PR.
  • If this PR requires a docs update, I have linked to that docs PR above.
  • If this PR modifies E2E tests, makes changes to resource provisioning, or makes SDK calls, I have run the PR checks with the run-e2e label set.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Copy link

changeset-bot bot commented Sep 9, 2024

🦋 Changeset detected

Latest commit: f87b76d

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 2 packages
Name Type
@aws-amplify/schema-generator Patch
@aws-amplify/model-generator Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

@ShadowCat567 ShadowCat567 marked this pull request as ready for review September 10, 2024 18:17
@ShadowCat567 ShadowCat567 requested a review from a team as a code owner September 10, 2024 18:17
@@ -20,6 +20,7 @@ export const getBackendOutputWithErrorHandling = async (
error instanceof BackendOutputClientError &&
error.code === BackendOutputClientErrorType.DEPLOYMENT_IN_PROGRESS
) {
// eslint-disable-next-line amplify-backend-rules/no-amplify-errors
Copy link
Member

@sobolk sobolk Sep 10, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now that I see the code around the suppression I do wonder what we should do about this long term.

  1. Should we be moving the error handling like this up? I.e. move this to relevant CLI commands instead of having this handling here?
  2. Should we re-classify this package (and other X-generators) and apply prefer-amplify-errors instead and keep local mapping at this level?

I would say 1. seems to be more correct. And I think lifting all these mappings to cli would be applicable to any command that pulls outputs. These don't seem to be specific to model generation.

@Amplifiyer @rtpascual what do you think?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm leaning towards 1 as well since this is already done for the ampx generate form command https://github.com/aws-amplify/amplify-backend/blob/main/packages/cli/src/commands/generate/forms/generate_forms_command.ts#L75-L137.

I believe moving this file to cli will get rid of the need for the duplicate code for forms as a side effect.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Btw. if we align on number 1 then this PR should go as is and work item should be opened to move this handling up separately.

@ShadowCat567 ShadowCat567 merged commit c10f6fc into aws-amplify:main Sep 10, 2024
37 checks passed
@ShadowCat567 ShadowCat567 deleted the implementing-errors branch September 10, 2024 22:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants