Thanks for the update. I can resume the evaluation as soon as the fixes are ready.

A couple of the issue tickets show that your team needs more information; does your team need that from me or from somewhere else?

These are the 3 open ones that I believe you're saying your team will fix soonish:

> We have already confirmed that the packages section is missing some dependencies and must be updated.

Good. What's the e.t.a. please? I would like to resume the evaluation when the tutorial is updated.

You now have proof that your own teammates are having problems because of your "Won't Fix" setting.

Your teammate failed to reproduce the security problem using your way, then was successful reproducing the security problem my way:

https://feedback.telerik.com/kendo-react-ui/1561910-missing-kendo-react-popup

Please update to be current-- if not for me, surely for your own teammates so they can diagnose failures correctly.

Now that I have proof positive that you're causing problems within your own company, with your own staff, I'm escalating this issue. Ideally someone higher up with bring you current.

> adding the missing dependency in your package.json will be enough to resolve the issues.

No it won't. There are a variety of issues here and it may help to enumerate them.

Issue 1. When people read the tutorial, it doesn't work. Your idea to edit package.json doesn't fix it for anyone else.

Issue 2. When my teammates read the tutorial, I can advise them that your tutorial is wrong/broken, and however that ends up being your team putting additional burden on me and my team to create a parallel errata in order make up for your your team's missing information.

Issue 3. When your team does fix the error, you'd need me to undo/retire my own team's parallel errata. What your suggesting would cause technical debt on my side i.e. you'd cause more work for my team in the future. This would mean I'd now have a documentation problem to deal with on my side, as well as a divergence in team training to correct on my side.

Issue 4. The discovery of the failure to launch the tutorial as written shows that no one on your team has proofread the tutorial using current security practices most notably the current security practice of using `yarn dlx`. Lack of technical proofreading is highly correlated with error and problems in other areas of a company. From my side, this issue is most definitely a security issue. And in fact, I've already discovered a different proofreading issue in the very same tutorial, and reported it to your team to fix.

Issue 5. The discovery of the failure to launch the tutorial as written shows that your team is not use full coverage automatic testing. Lack of full coverage automatic testing is a high risk factor for security weaknesses. All software has bugs, which is why my team has automatic testing and shift left testing in the security category, as well as in the reliability category. I encourage you and your team to do the team.

Issue 6. The delay caused by the tutorial failure impacts vendor selection, and has ripple effects into your company's sales organization. Specifically, the delay is causing me to ask the sales rep for additional time to do the evaluation. The tutorial problem has now eaten your time, his time, a couple of your other reps' time, my time, and my manager's time. Doing anything to package.json doesn't fix any of those issues.

Issue 7. This problem is a MTTR issue and used for a priori Bayesians for dealing with Kendo tech support. I.e. the long wall-time that it takes to deal with something that should be simple cuts deeply against Kendo as a vendor. When you and your company make it difficult to report problems, and are unable to fix them in a timely way (e.g. 24h) then it makes estimates of security responsiveness go through the roof.

Issue 8. I have to bill someone for my time finding the issue, reporting the issue, and dealing with the issue because it's still not fixed on your site. If you're planning to pay for my time fixing your team's errors, that's a fine solution-- let me know where to send the bill. If you're not planning to pay for my time, then surely you see that changing `package.json` doesn't magically cover the costs.

Issue 9. Your own teammates were unable to replicate the first two dependency bugs that I reported to your company. This is a full failure. If the tutorial had been correct, or if your team had been using `yarn dlx` as I recommended, then they would have found the issues immediately and also seen the diagnostic messages to help solve the issues.

Issue 10. Adding an item to package.json doesn't change PNP, nor yarn.lock. My guess is you're expecting some other step as well that you haven't mentioned, that updates PNP and/or yarn.lock. Without PNP and yarn.lock updated, the tutorial still doesn't work on my system. When PNP, package.json, yarn.lock are out of sync, then the app doesn't launch.

I hope this enumeration shows you that this issue is more involved, and your dismissal of the security solution of `yarn dlx` is at the core of all of this.

Can you please provide an e.t.a. for tutorial to work correctly?

In parallel, I'll ask the sales rep if it's possible to extend the evaluation period by a corresponding amount of time for your team to fix it. I will not proceed with my eval until it's fixed-- too many problems are turning up too early in the eval process.

Thanks for your considered response.

I agree with you about the "create-react-app" official recommendation. IMHO it's wrong in the same way. I'm sending a pull request now for it.

I agree with you too about "The main purpose of the getting-started article is to demonstrate how to use the KendoReact suite in React project". IMHO that's even more reason to add the latest stable information, because your article will be more successful for more developers who are making more progress using more professional tools. In other words, the article is intending to helpl sales-and-marketing, yes?

> As a side note, I tried to find information about the security risks of using "yarn create react-app" in yarn documentation, but to no avail.

When I try the tutorial using Yarn 3, what I see is these security errors that totally block the compilation... I reported these both in other issue reports here.

```sh
Module not found: Error: @progress/kendo-react-data-tools tried to access @progress/kendo-react-popup (a peer dependency) but it isn't provided by your application; this makes the require call ambiguous and unsound.
…
Module not found: Error: @progress/kendo-react-data-tools tried to access @progress/kendo-react-buttons (a peer dependency) but it isn't provided by your application; this makes the require call ambiguous and unsound.
```

Yarn 3 is significantly stronger/better/smarter at finding these kinds of ambiguous and unsound items. This is one of areas where Yarn 3 provides better security than Yarn 1.

My understanding-- and please correct me if I'm wrong-- is that Yarn 3 is turning up two ambiguous and unsound items in the KendoReact component.

Regarding the two syntaxes of "yarn create react-add" v. "yarn dlx create-react-app", the former runs a local installation of a global package (which could be falsified or corrupted) in the global environment (which could be exfiltrated or perturbed), the latter enforces a download then executes in a temporary environment-- which is more secure. The latter is what the yarn team recommends.

What you wrote isn't actually true-- the majority of developers who install Yarn now get Yarn 3.

What your tutorial is recommending is an old, expired, wrong, unstable, outdated way. I understand your perspective of wanting to offer multiple ways.

Best practice in software development is to publish the *current* way first, and then if you want, give older/outdated/dangerous options.

You can see this for yourself in the Yarn documentation, where the actual authors of the actual yarn tool show to use `yarn dlx` and explain why it protects from security risks.

It's important for you to be in sync with the actual yarn tool team IMHO. Thanks for considering this.

If Kendo cannot commit to keeping tutorials up to date, i.e. with current, correct, stable, versions, then the entire Kendo toolchain places unnecessary security threats into your developers' ecosystems.