Skip to content
This repository was archived by the owner on Feb 27, 2023. It is now read-only.

Conversation

rapropos
Copy link
Contributor

@rapropos rapropos commented Feb 4, 2016

Here are the TypeScript typings referred to in #26. As noted there, you probably want to hold off on merging this until JsonWebKey makes it into the main library, but I thought I would get it out in the field so that others could either review and make comments to improve it or use it off-label with a homebrew TypeScript fork.

@rmhrisk
Copy link
Contributor

rmhrisk commented Feb 4, 2016

@rapropos would you be interested in trying js-jose on node with my node-webcrypto-ossl polyfill? if so email me ar ryan _ hurst at hotmail

@rapropos
Copy link
Contributor Author

rapropos commented Feb 4, 2016

@rmhrisk, thank you for the offer, but I use Go on the server side instead of node (thanks to another great Square project), so probably wouldn't have much to contribute.

@alokmenghrajani
Copy link
Contributor

I think it's too bad that the types live in a different file. I'm open to renaming the files .ts and using the typescript compiler.

alokmenghrajani added a commit that referenced this pull request Mar 4, 2016
@alokmenghrajani alokmenghrajani merged commit 54df6e8 into square:master Mar 4, 2016
@rapropos rapropos deleted the typescript branch March 4, 2016 21:06
@rapropos
Copy link
Contributor Author

rapropos commented Mar 4, 2016

@alokmenghrajani: Although TypeScript is a superset of JavaScript in that valid JavaScript is valid TypeScript, in order to get the benefits of type checking we would have to rewrite the code to add type declarations. Just renaming all the .js to .ts wouldn't do the trick. I think of .d.ts files as sort of like an interface description language. Maybe that makes them seem less odious to you?

@alokmenghrajani
Copy link
Contributor

I was suggesting adding the types inline/doing the necessary rewrite and using the typescript compiler to generate the .js files. We already have a build process, I don't think this would make a big difference for anyone actually developing on this codebase.

@rapropos
Copy link
Contributor Author

rapropos commented Mar 4, 2016

It would affect deployment, I suppose. The logical way to organize the code would be along what TypeScript calls "external modules", so instead of everything getting slotted into the Jose/JoseJWE/JoseJWS globals, each file would be its own effective compile unit, and import the bits that they need from the others (like Utils).

So the method of including the library from client code would look different, maybe. I don't know how much of a concern that is for you, or whether it would be possible/easy to make shim code to gloss over it.

@rmhrisk
Copy link
Contributor

rmhrisk commented Mar 4, 2016

Yes, it is a few days of work to re-wite the library. We have been doing all of our similar work in TS and think it works well for platform components like this and would love to see js-jose be ts.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants