13 Answers, 1 is accepted
Thanks for posting to the Telerik Platform developer forums.
This is intentional. We did not include the declarations for common, third-party libraries used in the SDK, so they don't get included twice if you use them in your project as well. All the declarations necessary to use the SDK are in the "everlive-sdk" npm package (everlive-sdk/dist/declarations), but some of them are not included in the TS compilation process by default. If we do, what happens is that if you use the underscore library as well, and add it in the compilation process - there would be duplicate declarations for it and TS compiler would throw an error.
Here are the docs for using the Everlive SDK with TypeScript which explain how definitions are organized.
Let me know if this answers your question.
Regards,
Georgi Prodanov
Telerik by Progress
Rank 1
Hi Georgi,
Many libraries do include imports for their common third-party libraries in their SDK, and make them dependencies of their libraries. This would be the case with Everlive, since it requires underscore to work.
Regardless, I'm still confused as to why there is no import statement to assign _ to UnderscoreStatic. Since "UnderscoreStatic" is not tied to a file location, TS compilation, in most cases through a tsconfig, will have the compiler look within node_modules to find the package being imported in the declaration. It should not break TS compilation nor find two different instances.
By excluding this typing, there is no way for consumers who bundle this library in their build systems, using popular options like Webpack, to use this library. Essentially, you are telling the bundlers that there is no dependency needed to type "_" to some JavaScript module/library/function/class/etc.
I am curious as to how the Telerik team has avoided this issue when working with Angular 2+, perhaps I can learn a way around it so that the Angular compilers, Webpack bundlers, etc. just know that when trying to type Everlive that "_" is of type UnderscoreStatic.
Thank you for writing back. I will try to give a more detailed explanation as to why the definitions are not included by default this time.
The everlive-sdk package does depend on the underscore package, yes, and it is declared as such in its package.json. The only thing that is not being included by default is the definitions for underscore, not the library itself.
The "Underscore" NPM package does not include TS definitions (for now, as of version 1.8.3) so you need to get these definitions from third parties. This is why we have them included in our NPM package, in the everlive-sdk/dist/declarations/typings/globals/underscore/index.d.ts file. But they are not included in the compilation process, because if you have already installed "Underscore" and the typings for it, and we had included the definitions by default, the TS compiler would complain about duplicate declarations. This is why we chose to let the user include them if they were not already included in their project. Please note that at the time we released the SDK package, TS did not use the @types/* scoped package and there were fewer declarations management options at that time.
I have devised a small GitHub repository with an example, to help materialize what I am attempting to describe with the duplicate declarations. You can view it over here.
To supply the declarations to the typescript compiler you may add a reference to the above mentioned file, anywhere the TS compiler has access to. An easy way is to have a definition file (.d.ts file) with references, which is included in the compilation process.
Thank you for your feedback as it confirms that there is room for improvement, regarding the TS definitions "logistics", especially since TypeScript 2.0 was released. We are currently working on updates in our utilization scheme in order to make it more convenient.
Let me know if you need further assistance with using the TypeScript definitions.
Regards,
Georgi Prodanov
Telerik by Progress
Rank 1
Any update on this front? If not, would it be possible for me to fork the repo and publish a version with this fix?
We are constantly porting the project over to other developers and build machines, and each time we need to load dependencies from NPM we need to account for this issue. I'd like to be able to remove this step...especially as we start using TypeScript for newer projects running Ionic 2 as well.
Best,
Eric
Thanks for the follow up. I understand your concerns and will try to address them below.
Unfortunately, we don't expect to release the mentioned improvements soon, as we are still working on a few tasks with higher priority. The SDK is not open-sourced so it will not be possible to submit a pull request at this time.
We have a public GitHub repo, which contains the already built SDK and this should work for your purposes - you can fork it and just add the definitions to it in any way you see fit. But it has the same code you get by installing the "everlive-sdk" NPM module, minus the TS definitions.
Did you have the chance to try out my sample project on GitHub from my last message? I attempted to describe one approach that will help you to adapt the SDK definitions to your project requirements and easily include the definitions in the compilation process. If this sample was not helpful, can you please let us know what part was missing or was not explained well?
Allow me to illustrate my words with some further details. If you are bundling a project and wish to bundle our SDK along with it, you should be able to do it regardless of TypeScript definitions, as what is actually bundled is the JavaScript code and it is the only thing being executed. So at "bundle time" all you need to do is ensure the definitions are available to the TypeScript compiler at the time when Webpack (or whichever tool you are using - we use Webpack to bunde the SDK as well) is running the compiler. Once the JavaScript bundle is produced, include all the necessary definitions along with the bundle, so whoever is using it, has them included in their compilation process as well. You can do this using the @types convention or any other convenient way to point the compiler to the definitions.
Let me know if this answers your question.
Regards,
Georgi Prodanov
Progress Telerik
Rank 1
Hi Georgi,
For whatever reason, Ionic 2 (and I can't speak for Ionic 3, haven't gotten there yet!), doesn't ship with a declarations.d.ts file. I think Webpack may handle it all.
For our use, I think I will fork the repo -- I just didn't know which one it was. Do I have your permission to fork and publish it to npm as a global package, or would you like me to scope it to my enterprise?
Best,
Eric
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.
The definitions.d.ts 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.
Continuing on the above. The TypeScript compilation is not part of any framework because they are concerned only with JavaScript. So the compilation is the same whether you are using Angular, Ionic, NativeScript or anything else. TypeScript code is not executed anywhere, only JavaScript is. So no matter what framework you use or where the code you write will run, or if you are bundling (because you are bundling JavaScript, not TypeScript, for the above mentioned reasons), the compilation process must take place in advance and it is always done using the TypeScript compiler. So these techniques are not dependent on the framework, they only concern the TypeScript compilation process.
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.
Regards,
Georgi Prodanov
Progress Telerik
Somehow the above post appeared under Georgi's account (with whom we worked on the case) so I thought I'd rather apologize for the discrepancy.
We stay at your disposal for any questions or considerations.
Best regards,
Anton Dobrev
Progress Telerik
Rank 1
Hi Anton,
I have tried the minimal packaged sample sent. Compiling with Typescript from a TS Config works.
When you add in bundlers, like Webpack or Rollup, which a lot of modern frameworks include as part of their build processes, they will note the error. Bundlers use information from *.d.ts files, I presume, to run evaluations on what code may or may not break when compiled to JavaScript. Depending on how TypeScript is compiled, it may stop building if it notes that a type, in this case UnderscoreStatic, is referred to within the class definition. but is not imported it. To that extent, it could cause dependency management issues to the bundlers, which I believe it does.
Simply, adding the import statement to the library should fix this issue and your library can be used with bundlers like Webpack. These are becoming increasingly popular, so to stray away from fixing them could only hurt your adaptability.
I'd advise building an Ionic 2 project, using npm to install your library, trying to import it within a class and seeing what happens during build. I'd also recommend switching to lodash, as underscore has become increasingly less popular in the past few years.
But overall, I just don't want to have my builds break because there is manual intervention needed everytime the npm package everlive-sdk is added, or re-added, to my projects.
Best,
Eric
Rank 1
Please look at the following image. Sorry it has taken me this long to get it up -- there is no image upload function here...
I tried using the SDK with a simple Ionic 2 project (without Webpack) and had no problems with the suggested method. However, the setup could vary greatly when Webpack and ahead-of-time are involved. If your project is open-source, I would love to have a look at your setup, in order to be more helpful. If it isn't open-source, could you perhaps make a small sample project where the issue is reproducible - just the bare minimum in order to reproduce the issue. Maybe put it on GitHub. This way we'd be sure we are on the same page and can either provide a solution, or gain insight what we are missing in terms of usability. Thank you for your patience and understanding in this regard!
An idea I got while reading your latest message, was about the tsconfig file. You mention things work properly when you do use it and fail when the bundler tries to compile and I got the sense the bundler is not using the tsconfig file. Do you think this may be the case? Depending on your Webpack loader, there are ways to instruct the loader which config file to use for compilation. If you are using "awesome-typescript-loader" and your tsconfig file is named something like "tsconfig.dev.json", the loader might not be able to recognize and therefore use it. Here you can view the way to set it explicitly. They also enable you to pass TS compiler options to the loader directly, as stated at the bottom of the Readme. If you are using another loader, it should have similar options too. I honestly can't think of a reason for compilation for bundling to fail, if it succeeds by itself, when not bundling. I believe this means it's a matter of configuration and we should be able to find what piece of configuration is missing from the puzzle.
Regards,
Georgi Prodanov
Progress Telerik
Rank 1
https://github.com/ehorodyski/everlive-ionic-test
The import statement is in home.ts. It's as bare-bones as it can be.
I've submitted a small pull request which I believe fixes the issue. You didn't mention what command to run, so I assumed it's "npm run ionic:serve". The project starts and appears to be working properly after the changes I made. You can view the pull request here. I don't think you should have any problems when different developers are running the project this way.
Please let me know if this solution fits your needs.
Regards,
Georgi Prodanov
Progress Telerik