Skip to content

fix(types): no props typings in js files #13109

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

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

Ilanaya
Copy link

@Ilanaya Ilanaya commented Nov 1, 2023

What kind of change does this PR introduce? (check at least one)

  • Bugfix
  • Feature
  • Code style update
  • Refactor
  • Build-related changes
  • Other, please describe:

Does this PR introduce a breaking change? (check one)

  • Yes
  • No

If yes, please describe the impact and migration path for existing applications:

The PR fulfills these requirements:

If adding a new feature, the PR's description includes:

  • A convincing reason for adding this feature (to avoid wasting your time, it's best to open a suggestion issue first and wait for approval before working on it)

Other information:

This PR intended to fix an annoying problem that caused no type support for props in js files. As it said it ts documentation unspecified types defaults to any which caused the whole props object to become any.

Explicitly specifying the type unknown in generic should fully fix this problem.

References:
Similar PR addressing the same issue but with a bit harder solution

Known Vue language tools issues which are closed as upstream because of this bug.
vuejs/language-tools#2347
vuejs/language-tools#1537

computed: {
test() {
// @ts-expect-error Invalid typecast if `this.a` is not any
;/** @type import('../utils').IsAny<typeof this.a> */ (this.a)
Copy link
Author

Choose a reason for hiding this comment

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

If this.a is any this conversion wouldn't result in an error

Copy link

@dcq01 dcq01 left a comment

Choose a reason for hiding this comment

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

Hi! I'm a grad student working on a research project about using large language models to automate code review. Based on your commit e509aeb and the changes in types/test/v3/define-component-test.js, my tool generated this comment:

  1. Parameter Validation: Ensure that the props object is validated before being used in the defineComponent function. If props is expected to contain certain types or structures, there should be checks to confirm that these are present and valid.
  2. Handling Undefined or Null Values: If the defineComponent function is called with props that may be undefined or null, it should handle these cases gracefully.
  3. Type Checking: Implement runtime type checking to ensure that the values passed to props conform to the expected types.
  4. Error Handling: If the defineComponent function encounters an error due to invalid props, it should have a mechanism to handle such errors without crashing the application.
  5. Logical Evaluation: Verify that the defineComponent function correctly handles prop types. Ensure proper validation for the prop types defined in the props object.
  6. Direct Feedback: Add or modify tests that specifically check the behavior of the defineComponent function with various prop types. Confirm that components using different prop types behave correctly and that any errors are handled appropriately.
  7. Test Coverage: Ensure that there are existing tests that validate the behavior of defineComponent with respect to prop types. If there are no tests that specifically check for the correct handling of prop types, it would be prudent to add them.
  8. Edge Cases: Consider adding tests that cover edge cases for the prop types defined in the props object.
  9. Specificity: Ensure that subsequent tests accurately reflect the behavior of prop types. Revise any tests that do not align with this focus.
  10. Conclusion: Further verification of the defineComponent function's implementation and the associated tests is necessary to ensure that the functionality aligns with the new description. If the tests do not adequately cover the expected behavior of prop types, additional tests should be implemented.

As part of my research, I'm trying to understand how useful these comments are in real-world development. If you have a moment, I'd be super grateful if you could quickly reply to these two yes/no questions:

  1. Does this comment provide suggestions from a dimension you hadn’t considered?
    1. Do you find this comment helpful?

Thanks a lot for your time and feedback! And sorry again if this message is a bother.

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.

2 participants