Generator: Support later versions of NodeJS

[orfins]

As suggested by @derberg in our conversation in Slack:

I think it would make sense to actually just have "node": ">12.16" to enable others to use newer versions and report issues upfront so we know about them before we jump to the new version.

Personally I'd like to use this package in my node v15.5.0 project and provide feedback.

[github-actions[bot]]

Welcome to AsyncAPI. Thanks a lot for reporting your first issue.

Keep in mind there are also other channels you can use to interact with AsyncAPI community. For more details check out this issue.

[derberg]

@finsor Thanks!

@jonaslagoni @magicmatatjahu some time ago I've set this in the package.json but I feel like it would make sense to change to ">12.16" to enable early use for those that what to use the latest node.js versions. I'm not 100% sure it is good because I have a bad experience with versions without LTS. Nevertheless, I also understand users that want to always use the latest node with the latest features. What do you think?

[magicmatatjahu]

Yeah, sure but we should have info that we don't officially support non LTS versions, I mean, if someone will have a problem with Generator, then should first check if everything works in LTS :)

[derberg]

@magicmatatjahu yeap, this part https://github.com/asyncapi/generator#requirements would need to be updated, with the latest setting in package.json + an explanation about non-LTS versions, same about NPM actually. But with NPM 7 I already know that a few weeks ago somebody reported that it won't work with the generator

[orfins]

@derberg @magicmatatjahu Looks like it really doesn't work with npm 7:

$ npm -v
7.3.0
$ node -v
v15.5.0
$ ag hello.yaml @asyncapi/html-template -o html-output
Something went wrong:
TypeError: must call as: npm.load(callback)
    at Object.load (/{...}/node_modules/npm/lib/npm.js:130:13)
    at npmi (/{...}/node_modules/@asyncapi/generator/node_modules/npmi/npmi.js:189:9)
    at /{...}/node_modules/@asyncapi/generator/lib/generator.js:377:7

So what do we do with the PR?

[derberg]

yeap, it was reported in October and I worked on it https://github.com/asyncapi/generator/pull/440 but decided to drop efforts for npm 7. I see that node 15 is bundled with npm 7 -> so we have a problem 😄

still, I'm not sure it has anything to do with this issue and PR. In the end, it is about enabling others to give it a try to the generator with the latest node and npm as early as possible and report errors. I don't have a strong opinion here really, I do not mind having restrictions and I do not mind removing them. As anyway you see, we know about the problem upfront and did nothing about it 🤷🏼‍♂️

thoughts?

[stavalfi]

@derberg this issue shouldn't be bothered by the fact that npm@7 is not working well with asyncapi. it can be easily fixed by downgrade npm version npm i -g npm@<any-other-version>.

Also, our company uses yarn and I don't think that we are the only one (also there are pnpm users, deno users and users).

I find this node < 15 restriction very limited to my company because we are counting on specific features from node 15 in production code.

also, I don't think that a library in npm should determine the ___max___ node version which the user may use. it doesn't makes any sense (think about what happen when this library will be unmaintained)

the npm issues and node issues can be easily addressed in a bold comment in the README.md which specifies that npm7 is not working well with asyncapi and the users should downgrade the npm7 version until it is fixed. and if the user experience any issues in node 15, specify that this node version is not yet supported by asyncapi team.

Can we merge the PR about this?

[derberg]

@stavalfi thanks for taking the time to share your thoughts.

this issue shouldn't be bothered by the fact that npm@7 is not working well with asyncapi. it can be easily fixed by downgrade npm version npm i -g npm@.

I'm happy we agree.

Also, our company uses yarn and I don't think that we are the only one (also there are pnpm users, deno users and users).

It doesn't matter what technology you use internally to install ag. The issue mentioned here is with npm used by the generator internally to install templates. We still have issues with it because of not actively maintained npmi.
Interesting though would be to investigate if maybe yarn or pnpm have good and maintained API that we can call from the generator.

it doesn't makes any sense

🤷🏼

and btw

think about what happen when this library will be unmaintained

ain't gonna happen 😄

@orfins any thoughts? could you update your PR with proper info in the readme, for the users? or did you drop it and would like @stavalfi to take over?

[orfins]

@derberg I think everyone agrees that it shouldn't be limited, so I'll update the readme in a few minutes

[asyncapi-bot]

:tada: This issue has been resolved in version 1.1.9 :tada:

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot :package::rocket:

[stavalfi]

@derberg @orfins Thanks for your time and your cooperation.

Small Proposal:

I'm not sure I fully understand what goes internally inside the generator but maybe, just a proposal, avoid downloading your dependencies directly using a specific package-manager.

In our company, we use Yarn with workspaces and it seems to take too much time to run a small generator script because ___almost every time___, the generator downloads the same dependencies again.

And don't get me even start talking about @asyncapi/html-template which downloads puppeteer every damn time and it takes 60s (!!!!!) to do that. It makes our master-build in the CI takes 1m longer.

Let us download the dependencies you need so the selected (user) package-manager will find them.

[derberg]

Oh, these exclamation marks were unnecessary 😅

Yes, the generator has this issue that it somehow ignores already available dependencies and downloads them again, there is an issue with it, we did not find a solution for it. It should work this way, that if you want you can download deps on your own and the generator will get a symlink to the dep.

Atm, we do not have a great idea how to fix it. We would love some help in this area.

Regarding puppeteer, it is not what is downloaded, I bet you mean chromium. If you do not use the HTML template to generate PDF then you do not need it and can skip the installation. For example, it is ignored by the docker image as in docker we use dedicated chromium -> https://github.com/asyncapi/generator/blob/dc135fb7bb57c49266c5cecf380f453381e10be9/Dockerfile#L7. Try it out and if it works 🙏🏼 open a PR with a suggestion on how to explain it in the readme.

[stavalfi]

@derberg haha you are right!

I wasn't sure where to make the PR and also I couldn't find a reference for this env-var in async-api github org (https://github.com/search?q=org%3Aasyncapi+PUPPETEER_SKIP_CHROMIUM_DOWNLOAD&type=code)
please review the pr: https://github.com/asyncapi/html-template/pull/144

[derberg]

@stavalfi you picked the right place to write about it, thanks!