-
-
Notifications
You must be signed in to change notification settings - Fork 198
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
[RFC] Ship typescript types for the public APIs #816
Comments
Note that even if the IDE decides to take the |
@Lyrkan @weaverryan any opinion on this ? |
You can also reference the In long term I would suggest writing the source in typescript, couldn't find any considerations about that, but I don't think there are any drawbacks. |
that's irrelevant for this comment. My comment does not care about how the d.ts file is discovered by the IDE.
that's a totally different topic. And given that Encore deals with tons of optional dependencies, it might be hard to make it typed (without using |
That would be a great thing to have.
I kinda agree with stof regarding that point, it would probably require a lot of work for not that many benefits due to all the dependencies we work with (and all their supported versions). The only thing we really need is the public API to be typed correctly and recognized by IDEs. Also there is another small drawback: currently people can use an unreleased version of Encore quite easily by referencing the git repository in their |
This would make using a webpack.config.ts to configure Encore offer many benefits over the contextual help that the IDE can provide. I think this is a good proposal. |
Several IDEs (including PHPStorm/WebStorm and VS Code) are using the typescript type definitions to enhance their autocompletion for Javascript as well.
While investigating #815, I made a small experiment: I generated a index.d.ts file in webpack-encore to have type definitions for the Encore public API (which is defined and documented in index.js). And this solved the type support for PHPStorm 2020.2.
Given that the type declaration can be fully generated from the existing JSDoc, I suggest that we bundle it in the package.
For the record, here is the command I ran (at the root of the package):
tsc --declaration --allowJs --emitDeclarationOnly index.js
.To make this production-ready, a few changes would be necessary:
>=2.9
to be able to usetsc
in our publication process (no impact on projects using encore as that constraint is not enforced for enabling typescript features){function}
(but this will be hard to go fully there: configuration callbacks are dealing with options of loaders, but we cannot refer to the type definitions shipped in these loaders for any optional dependency)prepublishOnly
script doing that type generation before publishing the releases to npmAll the
improve JSDoc
steps could actually be done even without shipping typescript type declarations, as they would still proper better type definitions. And actually, I have part of them done locally as part of my experiment.What do you think @Lyrkan @weaverryan ?
My own vote would be in favor of including them, given that we don't need to maintain the
.d.ts
file manually.The text was updated successfully, but these errors were encountered: