-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
fix(repository-json-schema): update to pass openapi validation in azure #3504
fix(repository-json-schema): update to pass openapi validation in azure #3504
Conversation
@ericzon Thank you for the patch. I had a similar concern in the past - see #3309 (comment). |
FYI - the failure on Travis is a timeout error:
|
@slnode test please |
@nabdelgadir Please review the PR. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mostly LGTM, just a couple comments.
packages/repository-json-schema/src/__tests__/unit/build-schema.unit.ts
Outdated
Show resolved
Hide resolved
@nabdelgadir, is this good to land? |
@dhmlau not yet. @ericzon, what do you think about @raymondfeng's proposal?
|
Thanks @nabdelgadir . Let me assign it to you since you're already helping this PR. |
@nabdelgadir for me it's ok, compatible by default. @raymondfeng in 2 you propose to add some kind of extra & dynamic description like: "description": "[original description]... Product excluding fields id, name" right? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you @ericzon for the pull request! I agree we should emit schema titles that are compatible with a wide range of OpenAPI/JSON Schema consumers 👍
I disagree with the proposed implementation, let's find a better one.
@ericzon Would you please make the final update based on the team agreement? Thanks! |
Sure! I'm on that, I'll update the PR with the agreements.
|
Updated. Now is compatible by default & description includes information about model options. Example of model names & descriptions: "TechnicalData" "TechnicalDataExcluding_id-createdAt_" "TechnicalDataPartial" "TechnicalDataWithRelations" I tested in Azure to import the generated definition and is accepted. |
packages/repository-json-schema/src/__tests__/integration/build-schema.integration.ts
Outdated
Show resolved
Hide resolved
@ericzon I would love to see this pull request landed soon, let me know how can I help. |
2505074
to
c0fd6c2
Compare
@ericzon I have rebased your branch against latest master and squashed all commits into one. |
I would like the code building title suffix to be kept simple with hardcoded start/delimiter/end characters and also improve the code building options description to use I feel the current proposal is adding too much complexity that will make the code more difficult to maintain for us. |
@bajtos pushed a simplified version using stringify-object. |
1f8b31e
to
7535e69
Compare
@ericzon I have rebased your branch against latest master of strongloop/loopback-next. In the future, please use the following to pull in latest changes from upstream: git remote add upstream [email protected]:strongloop/loopback-next.git
git fetch --all
git rebase upstream/master |
@ericzon I don't see this change being applied to the patch. I don't see any new commits pushed around the time you have posted the comment. Did you perhaps forgot to |
86a1ef9
to
fe2119f
Compare
@bajtos now the changes are ready to check. I've squashed and rebase too. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please address my comments.
56f9d60
to
595fc54
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM with two nit-picks that can be ignored.
@raymondfeng WDYT?
packages/repository-json-schema/src/__tests__/integration/build-schema.integration.ts
Outdated
Show resolved
Hide resolved
8d4af5c
to
a3d8c00
Compare
a3d8c00
to
f4799ea
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Almost there!
"@hapi/hoek": "8.x.x" | ||
} | ||
}, | ||
"@loopback/build": { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please revert changes in package-lock.json
file. Now that you are not adding new dependencies, there is no need to change the lock file either.
For future reference: https://github.com/strongloop/loopback-next/blob/master/docs/site/DEVELOPING.md#working-with-dependencies
Here is the important part: Dependencies resolved locally within the monorepo must be excluded from package-lock files.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice, this problem was catched by our linter, I forget we have one in place!
See https://travis-ci.com/strongloop/loopback-next/jobs/238791798
Invalid package-lock entries found!
packages/repository-json-schema/package-lock.json
-> @loopback/build
-> @loopback/context
-> @loopback/core
-> @loopback/eslint-config
-> @loopback/metadata
-> @loopback/repository
-> @loopback/testlab
Run the following command to fix the problems:
$ npm run update-package-locks
Please don't run update-package-locks
and just revert changes in this file. We prefer to update lock files via https://renovatebot.com
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, I followed the suggestion of travis. Reverted.
@@ -15,6 +15,7 @@ import { | |||
import * as debugFactory from 'debug'; | |||
import {JSONSchema6 as JSONSchema} from 'json-schema'; | |||
import {JSON_SCHEMA_KEY, MODEL_TYPE_KEYS} from './keys'; | |||
const nativeUtils = require('util'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please use ES6 imports.
const nativeUtils = require('util'); | |
import {inspect} from 'util'; |
Or if you want to import everything:
const nativeUtils = require('util'); | |
import * as nativeUtils from 'util'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changes updated
…lidation in azure
f4799ea
to
c353a63
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👏
Let's get approval from @raymondfeng too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👏
Checklist
👉 Read and sign the CLA (Contributor License Agreement) 👈
npm test
passes on your machinepackages/cli
were updatedexamples/*
were updated👉 Check out how to submit a PR 👈
This PR is related with my comment in #1466 about problems found during the process of deploy an API in Azure.
With this PR is possible to deploy an API as "App Service" and connect it with the API Manager as OpenAPI.
I added the optional key 'itExtendsCompatibility' (boolean) in JsonSchemaOptions to tackle these cases. By default uses the current behaviour.
Added some tests, applied prettier & linter of the project.
P.S: by the way, trying to sign your CLA gives a 504 Error in Cloudfront.