-
-
Notifications
You must be signed in to change notification settings - Fork 98
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
feat: parseFromUrl does not resolve relative references (#504) #572
feat: parseFromUrl does not resolve relative references (#504) #572
Conversation
3288ba9
to
1344ba1
Compare
Kudos, SonarCloud Quality Gate passed! 0 Bugs No Coverage information |
1344ba1
to
1b38074
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.
@aeworxet thanks for the PR, there is one code smell to fix, please have a look https://sonarcloud.io/project/issues?id=asyncapi_parser-js&pullRequest=572&resolved=false&types=CODE_SMELL
@fmvilas @jonaslagoni @magicmatatjahu
hey folks, I'm not gonna jump into review of this one. I synced with @aeworxet offline several times to discuss possible solution, and yeah, I'm not the best person to approve what I already consulted and like 😆
so yeah, please review, especially @jonaslagoni that reported the request.
tl;dr it is about having similar solution for refs that we already have for parser, when parsing AsyncAPI file from the file system, to set base path to refs. In case of this PR it is about setting base path for refs but when parsing AsyncAPI file from URL or in a browser
1b38074
to
3f11dc9
Compare
@derberg |
We are facing same issue, so curious to know when this PR could be merged and available to use? |
Kudos, SonarCloud Quality Gate passed! 0 Bugs No Coverage information |
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 👍
@derberg are we waiting for other people to review it as well or can we merge it? 🤔 |
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.
@jonaslagoni no, I was most interested with your input as you did report the related issue.
we just need to update PR description properly so GitHub closes related issues.
So, you think we can close #344 with this one too?
You right, yea, I think we can, at least that's what I am gonna do 👍 |
@aeworxet just added the following to automatically close the issues once released 🙂
|
🎉 This PR is included in version 1.16.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
@all-contributors please add @aeworxet for code |
I've put up a pull request to add @aeworxet! 🎉 |
🎉 This PR is included in version 2.0.0-next-major.18 🎉 The release is available on: Your semantic-release bot 📦🚀 |
getBaseUrl()
was made a separate util to make code reuse possible.node-fetch
performs its own validation at fetch time, so no repetition of this task is made. The function only ensures thaturl
has type ofstring
and letsnode-fetch
deal with the rest.(typeof window !== 'undefined' && !options.hasOwnProperty('path'))
was added for the case ifgetBaseUrl()
gets called directly from inside of a browser (not fromparseFromUrl()
, but from<script>
) AND, amongst all, objectoptions
doesn't already have in it its own propertypath
with value. It is assumed in this case thatgetBaseUrl()
was not executed yet, so it's executed.If
getBaseUrl()
gets called from inside of a browser AND objectoptions
HAS in it its own propertypath
with a value - OK then, somehow it got that value, sogetBaseUrl()
does not get executed. This construction was inspired by test 'parse from string' in./test/sample_browser/index.html
.It is also assumed that, at the end of the day, user could have provided his own version of
options.path
- injected it at some point, for example.<
/>
in<anonymous-schema-x>
were considered custom HTML tags by browser's parser and didn't appear on screenmaking automated tests that assert visible elements' content to fail. So they are changed to HTML entities
<
/>
before insertion into the DOM and are replaced back to<
/>
by browser's parser at the insertion time, thus allowing automated tests querying elements' content to pass.puppeteer
to latest version (v17.0.0 at the moment of writing) just to make it more up to date.Fixes #344
Fixes #504