MrLeebo Github contribution chart
MrLeebo Github Stats
MrLeebo Most Used Languages

Activity

25 Nov 2022

MrLeebo

started

Started On 25 Nov 2022 at 09:27:44
Issue Comment

MrLeebo

Closes #253: Add change matchers, .toChange(), .toChangeBy(), .toChangeTo()

Adds three change matchers, .toChange(), .toChangeBy(), and .toChangeTo(), based on https://github.com/jest-community/jest-extended/issues/253#issuecomment-997087476.

// lunch.spec.ts
// totally fake example test script

test("adds lunch item", () => {
  expect(() => {
    lunch.add("pizza");
  }).toChange(() => lunch.count())
})

test("adding lunch items adds to cost", () => {
  lunch.add("salad"); // $5
  expect(() => {
    lunch.add("pizza"); // $7
    lunch.add("soda"); // $3
  }).toChangeBy(() => lunch.totalCost(), 10);
});

test("kids lunch comes with a free drink", () => {
  lunch.add("kids grilled cheese")
  expect(() => {
    lunch.add("kids drink")
  }).not.toChange(() => lunch.totalCost());
});

test("canceling order also clears the bill", () => {
  lunch.add("pizza");
  expect(() => {
    lunch.cancel();
  }).toChangeTo(() => lunch.totalCost(), 0)
});

test("a nice lunch at taco bell", () => {
  expect(() => {
    lunch.add("14 burritos"); // $2
  }).toChangeTo(() => lunch.totalCost(), 28);
}); 

Instead of one matcher with variant modes, I split it into three separate matchers so that the typescript definitions would not be overloaded.

 /**
     * Use `.toChange` when checking if a value has changed.
     * @example
     * expect(() => value++).toChange(() => value);
     */
    toChange<E = unknown>(checker: () => E): R;

    /**
     * Use `.toChangeBy` when checking if a value changed by an amount.
     * @example
     * expect(() => value--).toChangeBy(() => value, -1);
     */
    toChangeBy(checker: () => number, by?: number): R;

    /**
     * Use `.toChangeTo` when checking if a value changed to a specific value.
     * @example
     * expect(() => Model.deleteAll()).toChangeTo(() => Model.count(), 0);
     */
    toChangeTo<E = unknown>(checker: () => E, to?: E): R; 

What

This is an implementation of the matchers requested in https://github.com/jest-community/jest-extended/issues/253 with unit tests and documentation added.

Each of these matchers accept a checker callback function that it calls before and after invoking the mutator function. The checker function should access some mutable state value that can be modified by the code under test.

.toChange(checker)

Expect the state to have changed, or not to have changed when used with .not, by comparing to the before value with ===.

.toChangeBy(checker, by)

Expect the state to change by the given amount, which must be a number.

.toChangeTo(checker, to)

Expect the state to change to the given value.

Why

It's pretty common to test something that should make a change in your app, such as adding or removing an item from a list, then having an assertion to check that the count has changed. Often when we write these tests, we simply check the count of the list after the change.

// before
test("clears the list", () => {
  tasks.deleteAll();
  expect(tasks.count()).toEqual(0);
}); 

This test can pass if the function works as advertised, but it can also pass if the list was empty from the start. Change matchers can assert that the state was changed by the logic you're testing.

// after
test("clears the list", () => {
  expect(() => tasks.deleteAll()).toChangeTo(() => tasks.count(), 0)
}) 

Notes

First contribution 👋

Housekeeping

  • [x] Unit tests
  • [x] Documentation is up to date
  • [x] No additional lint warnings
  • [x] Typescript definitions are added/updated where relevant

Forked On 23 Nov 2022 at 10:42:13

MrLeebo

Naturally I think it brings enough value, I wouldn't have opened the PR if I didn't. I expect that I have an argument that would convince you, but with Thanksgiving preparations I don't have a lot of time to write up a full explanation, so I'll put in a brief, bulleted version for now and maybe provide more context if needed after the holiday.

  • The "easy" solution is to expect() the state before and after the state change.
  • This works well for basic unit tests, but doesn't necessarily scale as well for integrations / systems tests.
  • In those contexts, you're usually not setting up the full app state within the context of every test, you're working from a shared set of data fixture files or seed scripts.
  • So instead of
expect(Product.count()).toEqual(0)
Product.create()
expect(Product.count()).toEqual(1) 

What you're writing is more like

const initialCount = Product.count()
Product.create()
expect(Product.count()).toEqual(initialCount + 1) 
  • Reason is that since many tests share the same data fixtures, another test could add more products for other tests, so hard coded counts in this test will cause it to be brittle to changes in the fixtures.

  • Now, this code still isn't so bad, but sometimes these actions have second order effects, like updating the Product's price will update the product model, but it may also touch on other models (like an change audit / price history table that automatically gets an insert when the price changes)

  • It would be annoying to have to take the "initialCount" of every nested relation in each test to use the "easy" solution

  • Should a single test cover so much code? Again, these are integration tests not unit tests, they are meant to cover how the app works when all the pieces are brought together.

  • See "unit tests pass meme"

MyR86UeunZJcErQJmlEoEwWpAt56uIH2k2mHFqfsA95S2R.width-500_NbXJ1BV.png

Source

Commented On 23 Nov 2022 at 10:42:13

MrLeebo

Applies notes from code review: improves typescript types and asserts support for non-numeric values

Pushed On 17 Nov 2022 at 05:25:40
Issue Comment

MrLeebo

Closes #253: Add change matchers, .toChange(), .toChangeBy(), .toChangeTo()

Adds three change matchers, .toChange(), .toChangeBy(), and .toChangeTo(), based on https://github.com/jest-community/jest-extended/issues/253#issuecomment-997087476.

// lunch.spec.ts
// totally fake example test script

test("adds lunch item", () => {
  expect(() => {
    lunch.add("pizza");
  }).toChange(() => lunch.count())
})

test("adding lunch items adds to cost", () => {
  lunch.add("salad"); // $5
  expect(() => {
    lunch.add("pizza"); // $7
    lunch.add("soda"); // $3
  }).toChangeBy(() => lunch.totalCost(), 10);
});

test("kids lunch comes with a free drink", () => {
  lunch.add("kids grilled cheese")
  expect(() => {
    lunch.add("kids drink")
  }).not.toChange(() => lunch.totalCost());
});

test("canceling order also clears the bill", () => {
  lunch.add("pizza");
  expect(() => {
    lunch.cancel();
  }).toChangeTo(() => lunch.totalCost(), 0)
});

test("a nice lunch at taco bell", () => {
  expect(() => {
    lunch.add("14 burritos"); // $2
  }).toChangeTo(() => lunch.totalCost(), 28);
}); 

Instead of one matcher with variant modes, I split it into three separate matchers so that the typescript definitions would not be overloaded.

 /**
     * Use `.toChange` when checking if a value has changed.
     * @example
     * expect(() => value++).toChange(() => value);
     */
    toChange(checker: () => number): R;

    /**
     * Use `.toChangeBy` when checking if a value changed by an amount.
     * @example
     * expect(() => value--).toChangeBy(() => value, -1);
     */
    toChangeBy(checker: () => number, by?: number): R;

    /**
     * Use `.toChangeTo` when checking if a value changed to a specific value.
     * @example
     * expect(() => Model.deleteAll()).toChangeTo(() => Model.count(), 0);
     */
    toChangeTo<Val>(checker: () => Val, to?: Val): R; 

What

This is an implementation of the matchers requested in https://github.com/jest-community/jest-extended/issues/253 with unit tests and documentation added.

Each of these matchers accept a checker callback function that it calls before and after invoking the mutator function. The checker function should access some mutable state value that can be modified by the code under test.

.toChange(checker)

Expect the state to have changed, or not to have changed when used with .not, by comparing to the before value with ===.

.toChangeBy(checker, by)

Expect the state to change by the given amount, which must be a number.

.toChangeTo(checker, to)

Expect the state to change to the given value.

Why

It's pretty common to test something that should make a change in your app, such as adding or removing an item from a list, then having an assertion to check that the count has changed. Often when we write these tests, we simply check the count of the list after the change.

// before
test("clears the list", () => {
  tasks.deleteAll();
  expect(tasks.count()).toEqual(0);
}); 

This test can pass if the function works as advertised, but it can also pass if the list was empty from the start. Change matchers can assert that the state was changed by the logic you're testing.

// after
test("clears the list", () => {
  expect(() => tasks.deleteAll()).toChangeTo(() => tasks.count(), 0)
}) 

Notes

First contribution 👋

Housekeeping

  • [x] Unit tests
  • [x] Documentation is up to date
  • [x] No additional lint warnings
  • [x] Typescript definitions are added/updated where relevant

Forked On 17 Nov 2022 at 04:28:59

MrLeebo

I'm kinda questioning whether there's value in adding toChange(). Can you think of use cases where that'd actually be useful? I know it's what rspec has, just thinking aloud.

I think toChange() is actually more useful when inverted:

expect(action).not.toChange(checker) 

Commented On 17 Nov 2022 at 04:28:59

MrLeebo

Fix incomplete test description

Pushed On 09 Nov 2022 at 10:06:34
Issue Comment

MrLeebo

Closes #253: Add change matchers, .toChange(), .toChangeBy(), .toChangeTo()

Adds three change matchers, .toChange(), .toChangeBy(), and .toChangeTo(), based on https://github.com/jest-community/jest-extended/issues/253#issuecomment-997087476.

// lunch.spec.ts
// totally fake example test script

test("adds lunch item", () => {
  expect(() => {
    lunch.add("pizza");
  }).toChange(() => lunch.count())
})

test("adding lunch items adds to cost", () => {
  lunch.add("salad"); // $5
  expect(() => {
    lunch.add("pizza"); // $7
    lunch.add("soda"); // $3
  }).toChangeBy(() => lunch.totalCost(), 10);
});

test("kids lunch comes with a free drink", () => {
  lunch.add("kids grilled cheese")
  expect(() => {
    lunch.add("kids drink")
  }).not.toChange(() => lunch.totalCost());
});

test("canceling order also clears the bill", () => {
  lunch.add("pizza");
  expect(() => {
    lunch.cancel();
  }).toChangeTo(() => lunch.totalCost(), 0)
});

test("a nice lunch at taco bell", () => {
  expect(() => {
    lunch.add("14 burritos"); // $2
  }).toChangeTo(() => lunch.totalCost(), 28);
}); 

Instead of one matcher with variant modes, I split it into three separate matchers so that the typescript definitions would not be overloaded.

 /**
     * Use `.toChange` when checking if a value has changed.
     * @example
     * expect(() => value++).toChange(() => value);
     */
    toChange(checker: () => number): R;

    /**
     * Use `.toChangeBy` when checking if a value changed by an amount.
     * @example
     * expect(() => value--).toChangeBy(() => value, -1);
     */
    toChangeBy(checker: () => number, by?: number): R;

    /**
     * Use `.toChangeTo` when checking if a value changed to a specific value.
     * @example
     * expect(() => Model.deleteAll()).toChangeTo(() => Model.count(), 0);
     */
    toChangeTo<Val>(checker: () => Val, to?: Val): R; 

What

This is an implementation of the matchers requested in https://github.com/jest-community/jest-extended/issues/253 with unit tests and documentation added.

Each of these matchers accept a checker callback function that it calls before and after invoking the mutator function. The checker function should access some mutable state value that can be modified by the code under test.

.toChange(checker)

Expect the state to have changed, or not to have changed when used with .not, by comparing to the before value with ===.

.toChangeBy(checker, by)

Expect the state to change by the given amount, which must be a number.

.toChangeTo(checker, to)

Expect the state to change to the given value.

Why

It's pretty common to test something that should make a change in your app, such as adding or removing an item from a list, then having an assertion to check that the count has changed. Often when we write these tests, we simply check the count of the list after the change.

// before
test("clears the list", () => {
  tasks.deleteAll();
  expect(tasks.count()).toEqual(0);
}); 

This test can pass if the function works as advertised, but it can also pass if the list was empty from the start. Change matchers can assert that the state was changed by the logic you're testing.

// after
test("clears the list", () => {
  expect(() => tasks.deleteAll()).toChangeTo(() => tasks.count(), 0)
}) 

Notes

First contribution 👋

Housekeeping

  • [x] Unit tests
  • [x] Documentation is up to date
  • [x] No additional lint warnings
  • [x] Typescript definitions are added/updated where relevant

Forked On 07 Nov 2022 at 06:21:31

MrLeebo

@keeganwitt is there anything I can do to help progress this forward?

Commented On 07 Nov 2022 at 06:21:31
Issue Comment

MrLeebo

New `--alphabetize` switch: Sorts output file consistently

This PR adds a new --alphabetize switch that sorts the entries in the typescript output file alphabetically. This ensures the typescript file appears in a consistent sort order. Sometimes with dynamically generated docs, the order of the operations can change just depending on the timing of when each controller gets parsed. This can create trouble if you're checking your types into git. It can be difficult to review what changes were actually made when the only thing you can see in git diff is all of the operations being shuffled around.

Forked On 27 Oct 2022 at 01:12:49

MrLeebo

@drwpow is there anything else I can do to help move this along?

Commented On 27 Oct 2022 at 01:12:49

MrLeebo

started

Started On 26 Oct 2022 at 03:59:22
Issue Comment

MrLeebo

Add change matchers, .toChange(), .toChangeBy(), .toChangeTo()

Adds three change matchers, .toChange(), .toChangeBy(), and .toChangeTo(), based on https://github.com/jest-community/jest-extended/issues/253#issuecomment-997087476.

// lunch.spec.ts
// totally fake example test script

test("adds lunch item", () => {
  expect(() => {
    lunch.add("pizza");
  }).toChange(() => lunch.count())
})

test("adding lunch items adds to cost", () => {
  lunch.add("salad"); // $5
  expect(() => {
    lunch.add("pizza"); // $7
    lunch.add("soda"); // $3
  }).toChangeBy(() => lunch.totalCost(), 10);
});

test("kids lunch comes with a free drink", () => {
  lunch.add("kids grilled cheese")
  expect(() => {
    lunch.add("kids drink")
  }).not.toChange(() => lunch.totalCost());
});

test("canceling order also clears the bill", () => {
  lunch.add("pizza");
  expect(() => {
    lunch.cancel();
  }).toChangeTo(() => lunch.totalCost(), 0)
}) 

Instead of one matcher with variant modes, I split it into three separate matchers so that the typescript definitions would not be overloaded.

 /**
     * Use `.toChange` when checking if a value has changed.
     * @example
     * expect(() => value++).toChange(() => value);
     */
    toChange(checker: () => number): R;

    /**
     * Use `.toChangeBy` when checking if a value changed by an amount.
     * @example
     * expect(() => value--).toChangeBy(() => value, -1);
     */
    toChangeBy(checker: () => number, by?: number): R;

    /**
     * Use `.toChangeTo` when checking if a value changed to a specific value.
     * @example
     * expect(() => Model.deleteAll()).toChangeTo(() => Model.count(), 0);
     */
    toChangeTo<Val>(checker: () => Val, to?: Val): R; 

What

This is an implementation of the matchers requested in https://github.com/jest-community/jest-extended/issues/253 with unit tests and documentation added.

Each of these matchers accept a checker callback function that it calls before and after invoking the mutator function. The checker function should access some mutable state value that can be modified by the code under test.

.toChange(checker)

Expect the state to have changed, or not to have changed when used with .not, by comparing to the before value with ===.

.toChangeBy(checker, by)

Expect the state to change by the given amount, which must be a number.

.toChangeTo(checker, to)

Expect the state to change to the given value.

Why

It's pretty common to test something that should make a change in your app, such as adding or removing an item from a list, then having an assertion to check that the count has changed. Often when we write these tests, we simply check the count of the list after the change.

// before
test("clears the list", () => {
  tasks.deleteAll();
  expect(tasks.count()).toEqual(0);
}); 

This test can pass if the function works as advertised, but it can also pass if the list was empty from the start. Change matchers can assert that the state was changed by the logic you're testing.

// after
test("clears the list", () => {
  expect(() => tasks.deleteAll()).toChangeTo(() => tasks.count(), 0)
}) 

Notes

First contribution 👋

Housekeeping

  • [x] Unit tests
  • [x] Documentation is up to date
  • [x] No additional lint warnings
  • [x] Typescript definitions are added/updated where relevant

Forked On 17 Oct 2022 at 11:28:15

MrLeebo

It looks like the <TestFile> entries in the docs mdx file can't find any of the new matchers. Is there something I need to update in order to make that work?

Commented On 17 Oct 2022 at 11:28:15

MrLeebo

Add change matchers, .toChange(), .toChangeBy(), .toChangeTo()

Created On 17 Oct 2022 at 11:18:38
Create Branch
MrLeebo In MrLeebo/jest-extended Create Branchto-change-matcher

MrLeebo

Additional Jest matchers 🃏💪

On 17 Oct 2022 at 10:38:20

MrLeebo

Additional Jest matchers 🃏💪

Forked On 17 Oct 2022 at 10:38:17

MrLeebo

Add test for alphabetized operations and clean up operation tests

Pushed On 09 Oct 2022 at 04:02:05

MrLeebo

Fix required additional properties (#932)

  • Fix required additional properties handling

  • Optimize

Pushed On 09 Oct 2022 at 08:42:42

MrLeebo

add tkukushkin as a contributor for code, test, and bug (#944)

  • update README.md [skip ci]

  • update .all-contributorsrc [skip ci]

Co-authored-by: allcontributors[bot] <46447321+allcontributors[bot]@users.noreply.github.com>

Pushed On 09 Oct 2022 at 08:42:42

MrLeebo

Support Type Arrays for OpenAPI 3.1 (#917)

  • recursive types

  • example

  • tests for nullable as type array

Pushed On 09 Oct 2022 at 08:42:42

MrLeebo

bump deps (#945)

Pushed On 09 Oct 2022 at 08:42:42

MrLeebo

update GitHub Actions (#946)

  • update GitHub Actions scripts

  • add issue templates

  • fix lint warning

Pushed On 09 Oct 2022 at 08:42:42

MrLeebo

Tighten lint rules (#947)

  • tighten lint rules

  • update Ubuntu runner

Pushed On 09 Oct 2022 at 08:42:42

MrLeebo

use Vitest for test runner (#948)

Pushed On 09 Oct 2022 at 08:42:42

MrLeebo

update example schemas (#949)

  • update example schemas

  • submit codecov report for main

Pushed On 09 Oct 2022 at 08:42:42

MrLeebo

Merge branch 'main' into alphabetically-sort-transforms

Pushed On 09 Oct 2022 at 08:42:42

MrLeebo

Rewrite tests to test for alphabetization of specific object types

Pushed On 09 Oct 2022 at 08:39:17
Issue Comment

MrLeebo

Enhanced Custom Response Editor

Currently, the custom response field is a tiny textbox that can't easily be edited for JSON responses.

It would be great to be able to swap that out for a dedicated JSON editor component. Or a Postman-style interface where you choose the response type and get a different editor based on your pick. There are several implementations of JSON editors for React, but I'm not familiar enough with them to make a specific library suggestion yet.

My dream feature would be to be able to pass in an API schema (for instance, a swagger/OpenAPI JSON doc) and the editor would automatically use the schema to detect the available http handlers and to validate the given response against the response schema for that endpoint.

That would be a pretty epic enhancement. As an easier stop-gap measure that wouldn't require as much coding, the DevTools component could accept a Response Editor prop to allow the app author to plug in their own custom component for editing the responses:

<DevTools
  {...devToolProps} 
  renderResponseEditor={(props, devToolState) => (
    <MyAwesomeJsonEditor value={props.value} onChange={props.onChange} schema={swaggerDoc} />
  )}
/> 

Forked On 02 Oct 2022 at 04:56:38

MrLeebo

Yeah, a Headless component makes sense, especially if down the road you want to target other frameworks like vue and svelte.

I think having a strong default component is important too because a) the tool doesn't "demo" well if you can't see it in action, b) there are probably only a handful of aspects of the tool that the developer will seek to customize, they'll want to use the default component for the rest, and c) I can see a tool like this being a popular fixture in the demo apps of other component libraries, so a solid default component makes for good "branding" insofar as open source projects care about that.

Since I have started working on these changes already, should I incorporate factoring out a headless component into this branch, or do you have a headless branch started already that I should hold off for?

Commented On 02 Oct 2022 at 04:56:38

MrLeebo

Add styles, tests, and path transform

Pushed On 29 Sep 2022 at 04:06:07
Issue Comment

MrLeebo

Enhanced Custom Response Editor

Currently, the custom response field is a tiny textbox that can't easily be edited for JSON responses.

It would be great to be able to swap that out for a dedicated JSON editor component. Or a Postman-style interface where you choose the response type and get a different editor based on your pick. There are several implementations of JSON editors for React, but I'm not familiar enough with them to make a specific library suggestion yet.

My dream feature would be to be able to pass in an API schema (for instance, a swagger/OpenAPI JSON doc) and the editor would automatically use the schema to detect the available http handlers and to validate the given response against the response schema for that endpoint.

That would be a pretty epic enhancement. As an easier stop-gap measure that wouldn't require as much coding, the DevTools component could accept a Response Editor prop to allow the app author to plug in their own custom component for editing the responses:

<DevTools
  {...devToolProps} 
  renderResponseEditor={(props, devToolState) => (
    <MyAwesomeJsonEditor value={props.value} onChange={props.onChange} schema={swaggerDoc} />
  )}
/> 

Forked On 26 Sep 2022 at 08:01:45

MrLeebo

@coryhouse I started working on a "glow up" of the response editor, but I got side-tracked because I ended up needing to build more foundational components (like <Tabs>, <Tooltip>, <Select>, etc) to put it together. So it turned into a more general UI rework.

I'm trying to achieve these characteristics:

  • Incorporates tabbed interfaces
    • As the number of options grows, a purely vertical layout will be hard to navigate
    • As you mentioned, switching between a full editor vs canned custom responses
  • I'm also interested in allowing multiple instances of a handler to be assigned to the same endpoint:
    • They could have conditional triggers, like maybe the response delay is 0 normally, but if :id > 10 then it gets a 10 second delay, and :id > 100 returns a 400 status code. So one endpoint with 3 handlers attached to it.
  • Editable table for setting HTTP response headers
    • So within the Custom Response Form, there might be tabs for Body / HTTP Headers / Conditional Triggers etc
  • I think you would choose the API endpoint to edit first, then it drills down to the list of handlers you've created for that endpoint, then you have to choose the handler you want to edit.
    • That way the tool only has to render one response form at a time.

Commented On 26 Sep 2022 at 08:01:45
Create Branch
MrLeebo In MrLeebo/openapi-typescript Create Branchalphabetize-dist

MrLeebo

Generate TypeScript types from Swagger OpenAPI specs

On 26 Sep 2022 at 05:15:12

MrLeebo

Fix typo

Pushed On 24 Sep 2022 at 08:48:12

MrLeebo

Refactor sort into an --alphabetize flag and add test cases

Pushed On 24 Sep 2022 at 08:40:41

MrLeebo

Alphabetically sort output from transforms

This PR adds sorting logic to the various transform utilities that print the typescript output file. This should cause the typescript file to appear with a consistent sort order. Since the source document is an object key-value, the order of the keys can change each time you generate docs.

Having the keys shuffle around generally isn't a problem, but if you're checking your typescript file into git, it will be difficult to review the changes and it creates unnecessary churn because it's hard to tell which changes are legitimate and which changes are just operations getting moved around.

This PR currently breaks all of the snapshot tests if they weren't already in alphabetical order. I couldn't find a command within mocha to automatically regenerate the snapshots. Is there a command for that, or is this something I'd have to do manually?

Forked On 23 Sep 2022 at 09:42:11

MrLeebo

I factored out the cast to `as any[]` and made some changes below to satisfy the type violations caused by that.
On 23 Sep 2022 at 09:42:11

MrLeebo

Alphabetically sort output from transforms

This PR adds sorting logic to the various transform utilities that print the typescript output file. This should cause the typescript file to appear with a consistent sort order. Since the source document is an object key-value, the order of the keys can change each time you generate docs.

Having the keys shuffle around generally isn't a problem, but if you're checking your typescript file into git, it will be difficult to review the changes and it creates unnecessary churn because it's hard to tell which changes are legitimate and which changes are just operations getting moved around.

This PR currently breaks all of the snapshot tests if they weren't already in alphabetical order. I couldn't find a command within mocha to automatically regenerate the snapshots. Is there a command for that, or is this something I'd have to do manually?

Merged On 23 Sep 2022 at 09:42:12

MrLeebo

Commented On 23 Sep 2022 at 09:42:12

MrLeebo

Alphabetically sort output from transforms

Created On 23 Sep 2022 at 09:30:49
Create Branch
MrLeebo In MrLeebo/openapi-typescript Create Branchalphabetically-sort-transforms

MrLeebo

Generate TypeScript types from Swagger OpenAPI specs

On 23 Sep 2022 at 09:18:45

MrLeebo

Generate TypeScript types from Swagger OpenAPI specs

Forked On 23 Sep 2022 at 09:09:27

MrLeebo

Add expected_type to DecimalValidator

Created On 20 Sep 2022 at 10:49:11

MrLeebo

Add expected_type to DecimalValidator

Generated docs.json outputs the field as a string and not a number

Pushed On 20 Sep 2022 at 10:48:50

MrLeebo

started

Started On 18 Sep 2022 at 07:02:28