Repository navigation
Allow --declaration with --allowJs #7546
Description
Activity
PRs are welcomed. the fix should be removing the error, making sure the call is wired correctly, adding tests and making sure the declaration emitter handles the JS types correctly,
Reacted by Endel Dreyer, Benjamin Lupton, Steven, Martin Hochel and Thai Pangsakulyanont- added this to the milestone
on Mar 16, 2016 anyone currently working on this? If not i may take a stab at it.
Reacted by Steven and Madhu Rakhal Magaranyone currently working on this? If not i may take a stab at it.
got for it.
Reacted by spiffytech, Morten Christensen, Dwayne, Carlos Galarza, Eric Devine, Steven, Mat Schlenker and Brayan VeraThis would be definitely helpful 👍
👍
Take a look at dts-gen and let us know what you think. At the moment it doesn't do a good job of detecting changes between generations. But let us know if this helps!
Reacted by Blake EmbreyThanks Bowden Kelly (@bowdenk7)!
Would a simple approach like #7535 (comment) (internally) be enough to check if the definition has changed? It would be great to be able to run
dts-genin CI and error when there has been un-documented API changes to prompt an update to the.d.ts.Another use-case for this is that I have some plain JS tests that I use as both a form of documentation and as a way of validating that my code is callable from native ES5 in a way that is reasonable. All of my distributed source code is sourced from TypeScript and I would like to generate definition files for NPM publishing. However, because I have that one JS test sitting in my source tree I need
allowJs=trueso the test will correctly land in the output directory (not committed to source control) and be run along with all of my other tests. This, of course, means I can't have TSC output definition files for the rest of my project.Ben Greenier (@bengreenier) Wondering if you have made much progress on this? Let me know if there is anyway I can help speed things up. Would love to see this out in the wild.
69 remaining items
- For my use case, I have a large legacy library that was originally written in plain JS. Since then, I've started slowly transitioning it to TS. All of the publicly exported members have valid TS definitions, but I'm not able to compile the lib with auto-constructed d.ts files due to the fact that I need the allow JS flag in order to compile the TS files I have already converted (due only to the flag conflict). I know that generation of definition files for JS sources is a big task to take on, but perhaps a good first step would be to allow commingling of the flags with any exported members from .js files simply bring defined as type `any`?…On Sun, Sep 1, 2019, 9:41 AM Wesley Wigham ***@***.***> wrote: There's also technical value in fixing this, namely enabling using --incremental (and --composite) for projects with --allowJs, imo. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#7546?email_source=notifications&email_token=AECHXDS5DWSE2B4SCN6UCVDQHPWEVA5CNFSM4B6JHBJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5UGGNY#issuecomment-526934839>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AECHXDWVTY5ST43TVBXNREDQHPWEVANCNFSM4B6JHBJQ> .Reacted by Jasin Yip, tu4mo, Rohit Gohri, Radosław Miernik, Jonas and PIMBA
Wesley Wigham (@weswigham) Jordan Harband (@ljharb) - not trying to argue this isn't valuable, I'd have loved it when I needed it. Just trying to identify some other approaches.
Ben Sawyer (@industrialCoder) would it be possible to change the rest of the files across to .ts and apply
anyyourself?Reacted by Kevin Verdieckstudds when I say a large legacy library, I mean a very large legacy library... The time it would take to convert all of the .js files over to .ts and add the syntax required to make them valid TS (even typing everything as any) would be obscene to say the least. Is saying
type = importSourceType == js ? any : determineTSType(source)really that huge of a lift? Not familiar with the TS compiler code, but seems like this would be good bandaid solution that would help a lot of people out and should be much easier to implement than the solutions a lot of other people here are purposing....Reacted by Kevin Verdieck, Radosław Miernik, Jonas and yucj- That's my exact use case - generating Protobuf source code which includes both .js and .d.ts files.…On Wed, Sep 4, 2019 at 10:53 PM Christian Stewart ***@***.***> wrote: I generate some Protobuf files (.js and .d.ts) which I want to include with my library. I'd expect the Typescript compiler to pull the files together into a bundle and produce combined definitions, but I get the "simultaneous allowJs and declarations not allowed" issue — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#7546?email_source=notifications&email_token=AFLJ6KTEVJR5RBKLSL3RC7DQIAG4HA5CNFSM4B6JHBJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD54YOPI#issuecomment-528058173>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFLJ6KUME3FNKB6EKOADFMLQIAG4HANCNFSM4B6JHBJQ> .
Amit Beckenstein (@amitbeck) I solved it for now by generating types separately and using --allowJs=false on the type generation step.
I have an issue opened on TypeScript problems with understanding imported JSDoc types from imported node modules. It's currently flagged as backlog. Feel free to comment there to push this along: #33136. Getting this fixed would allow JavaScript authors to provide JSDoc types for their code that end users could take advantage of for type linting and Intellisense in VSCode with
allowjsset to true.At Unsplash, this is blocking us from using project references aka
composite(becausecompositerequiresdeclarationto be turned on).Glorious day! Thanks Wesley Wigham (@weswigham)! Looks like this is slated for 3.7? Man that is going to be a great release.
Reacted by Daniel Pereira and Frank TopelReacted by Jes Wulfsberg Nielsen, Connor Clark, Dmytro Yashyn, Thomas Eizinger, Shinigami, Rohit Gohri, Amit Beckenstein, Thomas Allmer, Steven, zernie and 16 moreReacted by Wesley Wigham, Dmytro Yashyn, Shinigami, Amit Beckenstein, Steven, Julio, Bnaya Peretz, Jan Nicklas, Andrew Plummer, Tobias Pickel and 1 moreReacted by Dmytro Yashyn, Thomas Eizinger, Tobias Cudnik, Shinigami, Aleksey Kulikov, Amit Beckenstein, Steven, Patrick Dahms, Bnaya Peretz, Jan Nicklas and 3 moreDoes the conversion mechanism recognize node packaging? It seems it generates one module per file, although Node.js exports one module per dependency.
A module is a file is a module; an npm package has 0, 1, or N files/modules.
Reacted by Nicky McCurdyYou are right. Still, it does not help with producing declarations compatible with the node module lookup mechanism. You may want to refer to this question on StackOverflow for an example of what is precisely happening: https://stackoverflow.com/questions/59564524/generating-typescript-declarations-for-re-exported-js-functions-in-a-node-js-mod
Reacted by Thomas Eizingeris this resolved?
Reacted by Lucas Moraes (Panik), Quetzal Rivera, Konstantin Shutkin, Pranav, Daniel Howe and ericfurspan-champ
From #7535, it would be useful for JavaScript package authors to have the ability to generate declarations from their project. This would help with getting started on a type definition (it would be populated with known interfaces/functions/types that are exported) and would also allow the creation of continuous integration scripts that check the JavaScript types with the hand-coded definition for inconsistencies.