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

[APITEST-766] Added Packages to Collection Schema #1352

Open
wants to merge 5 commits into
base: develop
Choose a base branch
from

Conversation

aditya-baradwaj
Copy link

@aditya-baradwaj aditya-baradwaj commented Feb 12, 2024

This PR adds the concept of packages to the collection schema and the postman-collection entity.
In the events object, we have a Listen (String) and Script Object to encapsulate all the data related to a script.
Inside the Script Object, we have the following -

  • type
  • exec
  • id

We are adding a fourth entity - Packages

Packages is an array of objects, each of which will contain the name of the package and the ID of the package. This enables us to correctly resolve the packages needed for the execution of the particular parent event.
The events object in the collection will now look something like this -

{
...,
"events": [
            {
                "listen": "prerequest",
                "script": {
                    "exec": [
                        "console.log('x');"
                    ],
                    "type": "text/javascript",
                    "packages": [
                      {
                        id: "<packageid-1>"
                      },
                      {
                        id: "<packageid-2>"
                      }
                    ],
                    "id": "51f1d8c7-6006-43e8-90f6-846cc8144d7f"
                }
            }
        ],
...
}

Implementation documents -


/**
* @arguments {Script.prototype}
* @type {Array<Object>}
Copy link
Member

Choose a reason for hiding this comment

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

This would provide more info about the interface:

Suggested change
* @type {Array<Object>}
* @type {Array<{ id: string, name: string }>}

@@ -62,6 +62,12 @@ _.assign(Script.prototype, /** @lends Script.prototype */ {
* @type {string}
*/
this.type = options.type || 'text/javascript';

/**
* @arguments {Script.prototype}
Copy link
Member

Choose a reason for hiding this comment

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

Typo?

Suggested change
* @arguments {Script.prototype}
* @augments {Script.prototype}

Copy link
Member

Choose a reason for hiding this comment

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

Do we even need this JSDoc tag? 🤔

* @arguments {Script.prototype}
* @type {Array<Object>}
*/
this.packages = options.packages || [];
Copy link
Member

Choose a reason for hiding this comment

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

Nit: newline after this.

@aditya-baradwaj aditya-baradwaj marked this pull request as ready for review February 15, 2024 06:42
@@ -62,6 +63,9 @@ _.assign(Script.prototype, /** @lends Script.prototype */ {
* @type {string}
*/
this.type = options.type || 'text/javascript';

this.packages = options.packages || {};
Copy link
Member

Choose a reason for hiding this comment

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

Let's keep the @type properties for packages. Needs to be done for line 52 as well.

@@ -25,7 +25,8 @@ describe('Collection', function () {
script: {
id: 'my-script-1',
type: 'text/javascript',
exec: ['console.log("This doesn\'t matter");']
exec: ['console.log("This doesn\'t matter");'],
packages: {}
Copy link
Member

Choose a reason for hiding this comment

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

Why do we need to add the empty key everywhere? It's supposed to be optional, no?

Copy link
Author

Choose a reason for hiding this comment

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

Yep yep, just needed to add this to the assertions after conversion since we're defaulting to an empty object, no need for this here.

@@ -10,7 +10,8 @@ describe('EventList', function () {
id: 'my-global-script-1',
script: {
type: 'text/javascript',
exec: 'console.log("hello");'
exec: 'console.log("hello");',
packages: [{ id: 'script-package-1', name: 'package1' }]
Copy link
Member

Choose a reason for hiding this comment

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

Needs to be updated?

@aditya-baradwaj aditya-baradwaj force-pushed the feature/APITEST-766-Add-Packages-to-collection-schema branch from 99457c4 to 805b014 Compare February 16, 2024 07:57
@@ -62,6 +63,9 @@ _.assign(Script.prototype, /** @lends Script.prototype */ {
* @type {string}
*/
this.type = options.type || 'text/javascript';

this.packages = options.packages || {};
Copy link
Member

Choose a reason for hiding this comment

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

Do we need to add a default value if this key is not present? If it's an optional property, I'm guessing... no?

Copy link
Author

Choose a reason for hiding this comment

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

@coditva Do we mean to make this completely optional?
For consistency purposes, I thought it would be best to have this property in all event objects, and rather than leaving it as undefined in the cases where it isn't available, it seemed better to have it as an empty object.

We can change this in such a way that we move this under an
if (options.packages) to make this completely optional, but it does not seem ideal IMO. Do let me know if this is not the case.

It would be completely optional from a User perspective in either way tho.

Copy link
Member

Choose a reason for hiding this comment

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

A whole lot of collections will start having empty packages field. I want to avoid it for the collections that don't even use it.

Copy link
Author

Choose a reason for hiding this comment

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

makes sense, I'll make it so that this.packages is only set if options.packages exists. Sounds good?

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