Thanks for the follow up. My name is Anton, stepping in for my colleague Georgi. Allow me to enter the discussion with some further thoughts.
file isn't supplied as part of the framework. It's a file, where you can list all the additional definitions you need in order to be included into the TypeScript compilation process. It's a convenience methodic - to put references to all other *.d.ts files in a single file, and point the TypeScript compiler to it. The latter is done via the TS config (the tsconfig.json
file). It's just more convenient to manage references this way. You can create it yourself and make sure it is included in the compilation process via the TypeScript compiler config file (tsconfig.json
), a process that can be automated as well.
I wanted to share the above theory, which I am sure you are familiar with, just as a good measure for clearing the whole setup and environment. I do agree that our SDK setup may not be optimal, especially with the latest advancements in the field and adoption of TypeScript, however, we tried to find the most suitable setup for now and the different environments used.
I hate to be so insisting but I'd like to ask you once again to have a look at the small sample my colleague prepared as it has a descriptive readme
file and has the bare minimum setup you need, in order to add the missing definitions to the compilation process. This file can be created once (and also automated) and reused when you are porting the app through developers, environments, build machines, etc.
This is not only the way to include definitions for Underscore, or only the way to make use of our SDK, it is simply a way to add definitions to the TypeScript compilation process.
To answer your question. I just spoke with the engineering manager and we find that modifying and publishing the package as public, in NPM for example, may lead to some confusion in other customers and developers using the package, discrepancies in the documentation, outdated documentation, the need for your team to keep both packages in sync (when we release updates, for example) and republish your custom package, etc. and ultimately may become a burden for both teams. Having said so, we'd rather prefer that you do not proceed with publishing a public modified package of the SDK. Nevertheless, you and every user of the SDK is permitted to use it to the extent of the license
Let me know if this answers your question.
Do you want to have your say when we set our development plans?
Do you want to know when a feature you care about is added or when a bug fixed?
Telerik Feedback Portal
and vote to affect the priority of the items