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

Milestone 1.5: Add a check for checking the version of third party type defs #9310

Merged
merged 17 commits into from May 24, 2020
Merged

Milestone 1.5: Add a check for checking the version of third party type defs #9310

merged 17 commits into from May 24, 2020

Conversation

nishantwrp
Copy link
Contributor

@nishantwrp nishantwrp commented May 14, 2020

Overview

  1. This PR fixes Add a lint check to check whether the type defs need to be updated #9287
  2. This PR does the following: Add a check for checking the version of third party type defs

Essential Checklist

  • The PR title starts with "Fix #bugnum: ", followed by a short, clear summary of the changes. (If this PR fixes part of an issue, prefix the title with "Fix part of #bugnum: ...".)
  • The linter/Karma presubmit checks have passed locally on your machine.
  • "Allow edits from maintainers" is checked. (See here for instructions on how to enable it.)
    • This lets reviewers restart your CircleCI tests for you.
  • The PR is made from a branch that's not called "develop".

PR Pointers

  • Oppiabot will notify you when you don't add a PR_CHANGELOG label. If you are unable to do so, please @-mention a code owner (who will be in the Reviewers list), or ask on Gitter.
  • For what code owners will expect, see the Code Owner's wiki page.
  • Make sure your PR follows conventions in the style guide, otherwise this will lead to review delays
  • Never force push. If you do, your PR will be closed.

@oppiabot
Copy link

oppiabot bot commented May 14, 2020

Hi, @nishantwrp. This pull request does not have a "CHANGELOG: ..." label as mentioned in the PR checkbox list. Please add this label. PRs without this label will not be merged. If you are unsure of which label to add, please ask the reviewers for guidance. Thanks!

@oppiabot
Copy link

oppiabot bot commented May 14, 2020

Assigning @kevinlee12 for the first-pass review of this pull request. Thanks!

@kevinlee12
Copy link
Contributor

kevinlee12 commented May 14, 2020

Mind the lint errors!

@nishantwrp
Copy link
Contributor Author

nishantwrp commented May 14, 2020

Done!

Copy link
Member

@vojtechjelinek vojtechjelinek left a comment

LGTM! Just two nits.

"""Checks the type definitions for third party libs
are up to date.
"""
stdout = sys.stdout
Copy link
Member

@vojtechjelinek vojtechjelinek May 15, 2020

Choose a reason for hiding this comment

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

This is quite useless to do, you can use sys.stdout directly on line 80.

Copy link
Contributor Author

@nishantwrp nishantwrp May 15, 2020

Choose a reason for hiding this comment

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

Done!

python_utils.PRINT('Starting type defs check')
python_utils.PRINT('----------------------------------------')


Copy link
Member

@vojtechjelinek vojtechjelinek May 15, 2020

Choose a reason for hiding this comment

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

Remove one empty line.

Copy link
Contributor Author

@nishantwrp nishantwrp May 15, 2020

Choose a reason for hiding this comment

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

Done!

@nishantwrp
Copy link
Contributor Author

nishantwrp commented May 15, 2020

@DubeySandeep @Hudda @ankita240796 PTAL!

Copy link
Member

@DubeySandeep DubeySandeep left a comment

@nishantwrp, Thanks for adding this check, I took a quick pass and left a few comments, PTAL!

import sys

import python_utils

Copy link
Member

@DubeySandeep DubeySandeep May 17, 2020

Choose a reason for hiding this comment

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

Do we use a newline between local imports?

Copy link
Contributor Author

@nishantwrp nishantwrp May 18, 2020

Choose a reason for hiding this comment

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

Removed


from . import linter_utils

_MESSAGE_TYPE_SUCCESS = 'SUCCESS'
Copy link
Member

@DubeySandeep DubeySandeep May 17, 2020

Choose a reason for hiding this comment

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

If this constant is used in all the linter files and we expect it to be the same in all the places then why don't we define this in a commonplace? Can you please move it to a commonplace, maybe linter_utils?

Copy link
Contributor Author

@nishantwrp nishantwrp May 18, 2020

Choose a reason for hiding this comment

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

Done

{
'name': 'Guppy',
'manifest.json': 'guppy',
'type_defs_file_name': 'guppy-defs-'
Copy link
Member

@DubeySandeep DubeySandeep May 17, 2020

Choose a reason for hiding this comment

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

filename* (here and elsewhere)

Copy link
Contributor Author

@nishantwrp nishantwrp May 18, 2020

Choose a reason for hiding this comment

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

Done

THIRD_PARTY_LIBS = [
{
'name': 'Guppy',
'manifest.json': 'guppy',
Copy link
Member

@DubeySandeep DubeySandeep May 17, 2020

Choose a reason for hiding this comment

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

Maybe manifest_dependency_key or manifest_dependency_name or ``manifest_frontend_dependency_name`?

Copy link
Contributor Author

@nishantwrp nishantwrp May 18, 2020

Choose a reason for hiding this comment

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

done

{
'name': 'Guppy',
'manifest.json': 'guppy',
'type_defs_file_name': 'guppy-defs-'
Copy link
Member

@DubeySandeep DubeySandeep May 17, 2020

Choose a reason for hiding this comment

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

Should the value be the complete filename? If not, then change the key maybe type_defs_filename_prefix?

Copy link
Contributor Author

@nishantwrp nishantwrp May 18, 2020

Choose a reason for hiding this comment

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

done

if lib_version[0] == '^':
lib_version = lib_version[1:]

files_in_typings_dir = os.listdir(
Copy link
Member

@DubeySandeep DubeySandeep May 17, 2020

Choose a reason for hiding this comment

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

Can we define this on top (of this method) so that we don't have to do this in the loop?

Copy link
Contributor Author

@nishantwrp nishantwrp May 18, 2020

Choose a reason for hiding this comment

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

done

files_with_prefix_name = []

for file_name in files_in_typings_dir:
if file_name.startswith(prefix_name):
Copy link
Member

@DubeySandeep DubeySandeep May 17, 2020

Choose a reason for hiding this comment

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

Maybe we can do it inline

files_with_prefix_name = [
    file_name for file_name in files_in_typings_dir
    if file_name.startswith(prefix_name)
]

Just trying to make this long method more readable and short and less branching.

Copy link
Contributor Author

@nishantwrp nishantwrp May 18, 2020

Choose a reason for hiding this comment

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

done

python_utils.PRINT('')
failed = True
else:
type_defs_file_name = files_with_prefix_name[0]
Copy link
Member

@DubeySandeep DubeySandeep May 17, 2020

Choose a reason for hiding this comment

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

filename*

Copy link
Contributor Author

@nishantwrp nishantwrp May 18, 2020

Choose a reason for hiding this comment

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

done

else:
type_defs_file_name = files_with_prefix_name[0]

type_defs_version = type_defs_file_name[len(prefix_name): -5]
Copy link
Member

@DubeySandeep DubeySandeep May 17, 2020

Choose a reason for hiding this comment

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

Can you explain the random -5 here? (Also add a code comment)

Copy link
Member

@DubeySandeep DubeySandeep May 17, 2020

Choose a reason for hiding this comment

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

I found this -5 is for .d.ts if so can we use len('.d.ts) and add a comment on top explaining that all type-defs filename ends with this?

Copy link
Contributor Author

@nishantwrp nishantwrp May 18, 2020

Choose a reason for hiding this comment

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

done

lib_version, type_defs_version))
python_utils.PRINT('')
failed = True

Copy link
Member

@DubeySandeep DubeySandeep May 17, 2020

Choose a reason for hiding this comment

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

Assume I have added a new typedef file for any dependencies so how will we make sure that the typedef filename has version + it's included in this list? [Basically how this lint test will make sure this happens for new type def files?]

Copy link
Contributor Author

@nishantwrp nishantwrp May 18, 2020

Choose a reason for hiding this comment

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

We'll have to add the third party lib in the list.

Copy link
Member

@DubeySandeep DubeySandeep May 19, 2020

Choose a reason for hiding this comment

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

is it resolved?

Copy link
Contributor Author

@nishantwrp nishantwrp May 20, 2020

Choose a reason for hiding this comment

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

I think we won't be adding third party libs frequently. When we can simply add it to the list.

Copy link
Member

@DubeySandeep DubeySandeep May 20, 2020

Choose a reason for hiding this comment

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

But we should have this check for any new typings we add, right? (To have this test future proof)

Copy link
Contributor Author

@nishantwrp nishantwrp May 20, 2020

Choose a reason for hiding this comment

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

I am unable to think of a way to automate this check. I mean not all files in package.json or manifest.json have typedefs. So, how do we know which ones to check?

Copy link
Member

@Hudda Hudda left a comment

Thanks, @nishantwrp . I've left a comment PTAL!

all_messages += (
third_party_typings_linter.check_third_party_libs_type_defs(
verbose_mode_enabled))
Copy link
Member

@Hudda Hudda May 17, 2020

Choose a reason for hiding this comment

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

Do not call it here, instead create a new file named other_linter.py and add this check under the OtherLintChecksManager class.

Copy link
Contributor Author

@nishantwrp nishantwrp May 18, 2020

Choose a reason for hiding this comment

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

Isn't this a general check like codeowners check. That check also is called this way.

Copy link
Member

@Hudda Hudda May 20, 2020

Choose a reason for hiding this comment

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

yep, you are right. Leave this then.

@nishantwrp
Copy link
Contributor Author

nishantwrp commented May 21, 2020

@DubeySandeep I don't think there might be issues with windows.

from . import third_party_typings_linter


class ThirdPartyTypingsLinterTests(test_utils.GenericTestBase):
Copy link
Member

@DubeySandeep DubeySandeep May 22, 2020

Choose a reason for hiding this comment

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

@nishantwrp, Can you please check whether the 100% coverage checks for linter files is enabled?

Copy link
Contributor Author

@nishantwrp nishantwrp May 22, 2020

Choose a reason for hiding this comment

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

Yup It is

@DubeySandeep
Copy link
Member

DubeySandeep commented May 22, 2020

@kevinlee12, @ankita240796, @Hudda PTAL!

@ankita240796, I've added to for reviewing the new test file which is similar to the release script test, so your review will be helpful. Thanks!

Copy link
Contributor

@ankita240796 ankita240796 left a comment

LGTM for typings, Thanks @nishantwrp!

@ankita240796 ankita240796 removed their assignment May 22, 2020
@nishantwrp nishantwrp removed their assignment May 22, 2020
Copy link
Contributor

@kevinlee12 kevinlee12 left a comment

lgtm for code owner files

@oppiabot
Copy link

oppiabot bot commented May 23, 2020

Hi @nishantwrp. Due to recent changes in the "develop" branch, this PR now has a merge conflict. Please follow this link if you need help resolving the conflict, so that the PR can be merged. Thanks!

@kevinlee12 kevinlee12 assigned nishantwrp and unassigned Hudda May 23, 2020
Hudda
Hudda approved these changes May 23, 2020
Copy link
Member

@Hudda Hudda left a comment

LGTM, thanks @nishantwrp

@kevinlee12 kevinlee12 merged commit b397ce0 into oppia:develop May 24, 2020
19 checks passed
@nishantwrp nishantwrp deleted the typings-update-check branch May 24, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add a lint check to check whether the type defs need to be updated
6 participants