-
Notifications
You must be signed in to change notification settings - Fork 14
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
Incompatible sparqljs Type Definitions #58
Comments
Hi, I'm very well aware of this issue. To give some context on this, we developed If we want to align the two type definitions, we will need to edit almost 80% of Of course, it's a major issue, and it should be fixed as soon as possible. However, I have not any free time to allocate to it before the end of the year. So, unless somebody is kind enough to contribute to this, we are stuck in the current situation. |
Some time ago I did this kind of update on my local fork, though on an older version of |
Just thinking about it, but a temporary solution could be to release on npm our own set of TypeScript definition for Of course, the long-term solution is to align ourselves with definitions available at DefinitivelyTyped, but this could be a good compromise in the meantime. What do you think about it @thatcort ? |
I think it depends on when @JuniperChicago thinks he can complete the type migration. If it's soon, I'm managing to avoid the problem for now by working on other parts of my codebase and hoping it all gets resolved before I need to return to it. If he thinks it will be some time, then your workaround seems worthwhile. Thanks! |
@thatcort @Callidon I am in the thick of it right now, and would like to be done this week. Is this fast enough? I am working through this task progressively, As an intermediate step, I am actually using the original |
That's fine for me. I have other deadlines to keep me busy until at least the end of the month. Plus I really appreciate the free labor that appeared as soon as I posted the issue, so whatever you can manage is amazing. |
Okay, fine for me too. I will upload to npm the "legacy" types package for |
A (very late) update on this topic: I will publish the package and update I apologize for the delay, but with the new lockdown in France happening at the same time as my Ph.D. defense, I've been very busy the past two weeks. |
And voilà, the new "legacy" types package is available as I've also updated @thatcort Do you think that's enough for your needs? |
Yes, seems so. Thank you! |
I tried using the updated library and unfortunately I don't think this approach will work. Because sparqljs-legacy-type is defining types for sparqljs, when trying to resolve sparqljs imports within my project files the types conflict. So configuring the tsconfig to use the correct definitions for sparql-engine will cause the types to not match what's expected by the other libraries and vice versa. Or maybe I'm misunderstanding something? |
Also congrats on your Ph.D. defense! |
Thanks 😄 The issue is that you cannot use both versions of SPARQL.js, because TypeScript can only compile using a single type definition file. That's a hard limitation of TypeScript, and I don't think it will ever change. If you use |
@Callidon @thatcort I am still working on contribution I commenced but had to pause for a week. It was my goal to use the latest sparql.js version where the first and most pervasive conflicts in type definitions center around the |
For me, the way to go is to replace all usage of @JuniperChicago If you are able to perform this migration, it could be a huge step forward for the framework 👍 Of course, the main drawback is that we introduce a major breaking change for all current users of the framework, as the API of all basic functions will drastically change. But I think such change is mandatory, and if we want to keep |
Describe the bug
This library includes its own type definitions for sparqljs. These definitions conflict with the ones hosted on DefinitelyTyped that are used by other projects. These incompatibilities make it very difficult to use sparql-engine in an application that also uses other libraries that depend on the DefinitelyTyped defintions. Importing from 'sparqljs' will resolve to @types/sparqljs rather than the custom ones (which is what is desired some of the time). Could you please transition to using the types provided by DefinitelyTyped (ideally from v3)?
To Reproduce
Steps to reproduce the behavior:
I've managed to alter my .tsconfig file to prefer one set of definitions over the other, but this fails when it needs to use both.
Expected behavior
Only a single set of types should exist with the given name. Apps within the TypeScript SPARQL ecosystem should be able to share type definitions as much as possible.
The DefinitelyTyped definitions are here: https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/sparqljs/index.d.ts
The text was updated successfully, but these errors were encountered: