-
-
Notifications
You must be signed in to change notification settings - Fork 96
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
Integrate smoya/multi-parser-js into asyncapi/parser-js #963
Comments
Makes sense to me 👍 |
Bounty Issue's service commentText labels: @asyncapi/bounty_team |
@smoya I think you should ask the Asyncapi org to add this issue under GSOC 2024 idealist. It would be a good contribution to have in the parser-js. |
This is part now of the AsyncAPI Bounty Program 2024 Q2. Additionally, the GSOC 2024 ideas submission period finished last month, and we got accepted. |
@smoya if that works, I guess we can start thinking about pulling other projects inside parser-js for better maintainance and cooperation - like avro, protobuf, openapi and raml data parsers? and then we can also work on something that @jonaslagoni brought up in past, that DX of using parser with schema parsers is hard, so we could enable publishing of parser-js on steroids, with schema parsers included by default (while still publishing parser alone of course, lightweight for web) |
It makes sense to me, yeah.
+1. I wasn't aware of this suggestion but i really like it. I've found myself involved in the issue of having to manually load the schema parsers all the time so I believe it will be so helpful for lot of users who just want everything to work at once. |
yeah, I see the same with |
I want to give a try to this issue and want to work on it. |
Hi @Vishal2002, thanks for showing interest. Let's wait at least a day since more contributors could jump in as well.
In your case, you fall under the third category. |
@smoya I want to work on this issue |
Same answer as the one I provided to @Vishal2002 in #963 (comment) |
@smoya in case you don't get experienced candidates for this one, maybe you can wait for @ayushnau (maybe he will be interested) as he is going to work now on basically the same (with small differences) asyncapi/generator#1044 - so monorepo in generator. Once he finish it, he can then do the same here maybe. Just an idea, I did not even check with @aeworxet if it is possible but I guess yes 🤔 you do not have to decide today or tomorrow, you can decide in a month |
Yeah, good advise. I'm still evaluating each candidate individually in the meantime. |
@smoya I'm excited about the opportunity to collaborate on this with you, I would love to work on this. Looking forward to it! |
I will be available starting from next Monday. to pay full attention to this. |
@ayushnau are you gonna work on this then? If so, when are you finally planning to do it? Thanks! |
i am on it once it got assigned to me. |
As spoken in Slack, you are working in asyncapi/generator#1044 in parallel. You mentioned you need a couple of weeks to finish such a task. Let's wait 2 weeks until I assign this issue to you. |
sure will do that. |
@smoya I would love to work on this please assign this issue to me. |
@asyncapi/bounty_team issue got assigned today to @ayushnau |
Bounty Issue's Timeline
Please note that the dates given represent deadlines, not specific dates, so if the goal is reached sooner, it's better.Keep in mind the responsibility for violations of the Timeline. |
Due to the fact Ci has been broken since long ago (we were not aware), and considering it took me some time (days) figuring out the reason, I believe @ayushnau should request an extension of 1 week for this Bounty Program delivery. cc @aeworxet |
Upon request of the AsyncAPI Maintainer, who is responsible for the resolution of the Bounty Issue from the AsyncAPI's side (@smoya), all remaining target dates of the Bounty Issue's Timeline are extended by one calendar week. Bounty Issue's Timeline Extended
Please note that the dates given represent deadlines, not specific dates, so if the goal is reached sooner, it's better.Keep in mind the responsibility for violations of the Timeline. |
I am writing to inform you of a recent change in our release process for the GitHub action. The release process, which was previously managed using semantic release, has now been transitioned to changeset. This unexpected shift has caused some delays, as I was not fully prepared for the new process. Consequently, I kindly request an extension of two weeks to accommodate this transition and ensure a smooth and accurate release. Thank you for your understanding and consideration. |
I agree the uncertainty nature of this issue, the knowns VS unknowns, and the several areas this issue affects (code, CI, CD) makes a difficult and, somehow, unpredictable one. Being honest, I had some doubts few days ago if this task should be given an extension or not, but atm I truly believe it should get it. @aeworxet has the last words. |
Upon request of the Bounty Program Participant (@ayushnau), all remaining target dates of the Bounty Issue's Timeline are extended by two calendar weeks. Bounty Issue's Timeline Extended
Please note that the dates given represent deadlines, not specific dates, so if the goal is reached sooner, it's better.Keep in mind the responsibility for violations of the Timeline. |
@ayushnau After merging #1036 and related PRs, the release of both packages happened. I tested the (node:55793) Warning: To load an ES module, set "type": "module" in the package.json or use the .mjs extension.
(Use `node --trace-warnings ...` to show where the warning was created)
/Users/smoya/dev/asyncapi-parser-example/node_modules/@asyncapi/parser/esm/index.js:1
import { DiagnosticSeverity } from '@stoplight/types';
^^^^^^
SyntaxError: Cannot use import statement outside a module
at wrapSafe (internal/modules/cjs/loader.js:1001:16)
at Module._compile (internal/modules/cjs/loader.js:1049:27)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:1114:10)
at Module.load (internal/modules/cjs/loader.js:950:32)
at Function.Module._load (internal/modules/cjs/loader.js:790:12)
at Module.require (internal/modules/cjs/loader.js:974:19)
at require (internal/modules/cjs/helpers.js:93:18)
at Object.<anonymous> (/Users/smoya/dev/asyncapi-parser-example/node_modules/@asyncapi/multi-parser/cjs/parse.js:6:17)
at Module._compile (internal/modules/cjs/loader.js:1085:14)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:1114:10) |
@smoya working on it. will update you once i fix it. |
After a set of delays that were beyond the control of the Bounty Program Participant Bounty Issue Completed 🎉@ayushnau, please go to the AsyncAPI page on Open Collective and submit an invoice for |
Context
@smoya/multi-parser is a library that allows users to parse an AsyncAPI document and get an output model based on a desired Parser-API version. Additionally, it allows to convert models from one Parser-API version to another.
This tool is required by some AsyncAPI tools that use the Parser-JS and have to send the parsed document model to another library, which could be compatible with a different Parser-API version than the one used in that particular version of the Parser-JS.
You have several examples of usage here:
Current issues
1. 👤 Ownership
@smoya/multi-parser is a library hosted in a GH repository under my particular ownership (@smoya). Not a big issue per se, but I don't wanna be the only maintainer of such a tool. I thought on donating this to AsyncAPI org (TSC would need to vote first) but the reality is that won't be needed, see next point:
2. 🔃 Release is not in sync with Parser-JS
Every new Parser-JS release is not triggering an update on the @smoya/multi-parser. I agree I could configure a bot like Renovate (Dependabot doesn't allow NPM package aliases, and this package makes use of them) to try update those.
But still we have two issue with that situation:
The solution I propose
To integrate @smoya/multi-parser code into the Parser-JS repository, and to release two packages on each Parser-JS release:
@asyncapi/parser
, the current one that is already happening.@asyncapi/multi-parser
, this a new one.In that way, everything gets in sync, and also, by adding tests, we could ensure new versions of the Parser-JS are working with the
@asyncapi/multi-parser
package. The same when we adopt a new version of the Parser-API in the Parser-JS, support in@asyncapi/multi-parser
will be added in the same PR.That means, we should have a monorepo model in this repository.
Due to the fact
@asyncapi/multi-parser
has as dependency the Parser-JS but not only once, but once for each Parser-API version (atm 3 aliased Parser-JS deps pointing to different version of the Parser-JS), plus the fact the library will be used only by few particular libraries and most users won't need it ever,@asyncapi/multi-parser
should be released completely as a separate package.Examples of monorepo within AsyncAPI can be found here:
Some discussions in Slack about that topic:
BTW, since @smoya/multi-parser is under Apache 2.0 license, copying code right directly into the Parser-JS is completely legal, and since Parser-JS uses the same license, no need to specify any atribution of change on the license. So no need to even first do the donation to AsyncAPI GH org :) Additionally, I'm giving my written approval to do whatever is needed with that code so it can be integrated into the Parser-JS. Once that's done, and all dependants update to
@asyncapi/multi-parser
, I will completely archive @smoya/multi-parser in favor of@asyncapi/multi-parser
.cc @jonaslagoni @magicmatatjahu
The text was updated successfully, but these errors were encountered: