Js-cookie: Typescript Support

[JefferyLiang]

I want to use it in my vue project with Typescript.

but it don't support typescript

could you write the index.d.ts to support Typescript?

[jaredpetersen]

@JefferyLiang It looks like someone has already added support for typescript via the @types/js-cookie package. It's working for me so far.

Download it via npm install @types/js-cookie --saveDev.

[FagnerMartinsBrack]

See https://github.com/js-cookie/js-cookie/issues/378, https://github.com/js-cookie/js-cookie/issues/124 and https://github.com/js-cookie/js-cookie/issues/50.

Do we need to add an entry on the Wiki as TypeScript being a community supported feature?

[jaredpetersen]

@FagnerMartinsBrack js-cookie shows up in TypeSearch so I don't know that it's necessary. If we decided to include it, I think the README is a better location though. I view the Wiki as more in-depth knowledge and if I'm evaluating whether or not I can use a library, the README is the first place I look.

[FagnerMartinsBrack]

Well, let's see if anybody else gets confused with this. If they do, then we add an entry on the README.

[jleclanche]

@FagnerMartinsBrack all four of the github issues show up in a google search for "js-cookie types". Is there a reason not to include index.d.ts in the library? js-cookie boasts "heavily tested" as a feature, and type definitions are definitely useful for the library itself as a testing feature.

[FagnerMartinsBrack]

@jleclanche There's no need for a type definition to test js-cookie in an effective manner, the "heavily tested" assertion still holds true if you change any part of the code and run the tests from the "/test" folder. Static testing is the weakest kind of testing. Duck typing is enough for most use cases and with 100% behavior test coverage you don't need anything else.

Is there a reason not to include index.d.ts in the library?

js-cookie is already a decade old and JavaScript is 23 years, we don't want the effort to maintain type definitions for a technology that might be gone in 5 years. We prefer to support vanilla JS which has been proven stable regardless of all the cycles of frameworks and transpilers.

[jleclanche]

@FagnerMartinsBrack I don't follow the logic. If the tech is gone in 5 years then remove the type definitions?
Type definitions change exactly as much as your API, which is rock stable as it has been around for, as you said, a decade.

[FagnerMartinsBrack]

@jleclanche The logic is that we don't want to maintain support for TypeScript. The community added support in another repository, see https://www.npmjs.com/package/@types/js-cookie.

See here for the original discussion: https://github.com/DefinitelyTyped/DefinitelyTyped/pull/4691

[jleclanche]

All I'm pointing out is that you have three github issues prodding for it, it shows up on google so you can expect to keep getting them. Suit yourself if you don't; personally I think it's a bit silly since it would actually be beneficial to the project to typecheck itself.

[FagnerMartinsBrack]

@jleclanche Feel free to create a PR to add the community supported repository in the README. Maybe that will stop so many issues popping up as I mentioned earlier.

[jleclanche]

I'll gladly file a PR to help introduce definitions, typechecking and adding it all to CI, but I most definitely will not encourage that type of head-sand interaction.

[FagnerMartinsBrack]

@jleclanche We won't add typescript to this repo as per past discussions. It's ok to add a link to the community supported definitions for ppl looking for it, not to add the definitions in the repository or make changes in the CI. There's no reason to do so.

[markcellus]

FYI, I'm now maintaining cookie-esm that has built-in TypeScript support.

[carhartl]

I believe TypeScript is going to stay. If not, the other day I removed bower support, I’m ok with removing TypeScript definitions 5 years from now :)

But I’m new to TypeScript development. Since definitions exist via DefinitelyTyped I’d like to understand what the advantage is of having definitions as part of this repo compared to installing them from @types? Is it about one package less one needs to think of installing? Is it that you trust more in the definitions if they were provided by the maintainers of the library?

[carhartl]

Well, with the release of v3 beta the definitions are slightly out of date, so that may answer my question at least partly.

[carhartl]

I’m willing to pick this up for v3.

[carhartl]

Definitions though, not going to rewrite the library in TypeScript.

Except in a fork 😬

[jleclanche]

@carhartl Great!

But I’m new to TypeScript development. Since definitions exist via DefinitelyTyped I’d like to understand what the advantage is of having definitions as part of this repo compared to installing them from @types? Is it about one package less one needs to think of installing? Is it that you trust more in the definitions if they were provided by the maintainers of the library?

Both of these are correct :) And the project can also use the definitions in CI to do some type checking and add to the test suite's robustness.

[FagnerMartinsBrack]

And the project can also use the definitions in CI to do some type checking and add to the test suite's robustness.

@jleclanche The test suite is robust enough without TypeScript. TypeScript has no value to the test suite in this project, we've never got any bugs because of problems related to types, only due to unintended changes in behavior (and even that the occurrence of bugs was very small). In development time, 100% of the bugs are picked up by running the test suite after every change.

It seems based on this thread that it does have some value for consumers of the library, probably to be able to understand and validate the signature of the method at compile-time and use supported IDEs.

I have no problem with TypeScript, as @carhartl said:

I’m ok with removing TypeScript definitions 5 years from now :)

[jleclanche]

@FagnerMartinsBrack Do it, don't do it, I have zero skin in that game. If you're that adamant it won't give the project value, then whatever. I'm just really glad type inclusion is being reconsidered given that it has value to users.

[FagnerMartinsBrack]

Sorry, @jleclanche I don't understand. Why are you calling me "adamant"? Can you please keep the class, stop name-calling unnecessarily and keep the discussion on topic? Thanks.

[jleclanche]

"Adamant" was not meant as an insult. To rephrase: "If you're that convinced …". No name-calling intended here.

Edit: I'm muting this thread now.

[jstrimpel]

@FagnerMartinsBrack: @jleclanche is not @jstrimpel. :)

[FagnerMartinsBrack]

@jleclanche I'm not "convinced" of anything here or "adamant", whatever that means. We're simply discussing tradeoffs and I'm telling the thread about my experience in js-cookie, let's keep like that without subjective assumptions among each other.

[FagnerMartinsBrack]

Here's the permalink for the definition as of today for our future selves: https://github.com/DefinitelyTyped/DefinitelyTyped/blob/34468989d6c0f0cacacd2ae88d32f1ba9665146d/types/js-cookie/index.d.ts

[markcellus]

I’d like to understand what the advantage is of having definitions as part of this repo compared to installing them from @types

@carhartl maybe I can help provide some clarity here. So types for this package can absolutely be created and used from the DefinitelyTyped packages. But a common problem is that the corresponding js-cookie types (mentioned by @FagnerMartinsBrack above) may get out of sync with the code changes made to this repository. If that ever happens, it will cause code to break for typescript consumers. This is no longer a problem if this package is written in TypeScript and generates its own corresponding declaration file.

Hopefully that helps!

[carhartl]

Thanks, that‘s what I realized by now.

if this package is written in TypeScript

Don‘t think I will go that far. Definitions will have to do.

[markcellus]

Yeah, just keep in mind that if the source files arent written in TS, the declaration file can still get out of sync (even if its in this repo) if you forget to manually update it to match the code in the JS files.

[carhartl]

I started reading the official guide regarding type declarations and it says:

If your package is not written in TypeScript then the second [publishing to the @types organization on npm] is the preferred approach.

http://www.typescriptlang.org/docs/handbook/declaration-files/publishing.html

I’m going to follow this advise (and add a note regarding TypeScript types to the documentation) and leave it at that.

If we’d manage to keep the transpiled source below 800b gzipped I’d be open to rewrite this tiny library in TypeScript, or create a _ts-cookie_ fork or whatever, if only for the fun of learning, but it’s mostly a matter of finding the time.

[carhartl]

Ah, and I’m going to send a PR to the @types repo for keeping the declarations up-to-date...

[murbanowicz]

Wouldn't you want to migrate code-base to TS? I could help with that.

[ofekshalom]

Hi, i"m using js-cookie with typescript. I installed @types/js-cookie. when i try to test some function. jest fails and the output is: cannot find module "js-cookie" from "filename".
however ......
you might want to include a file extension in your project, or update moduleFileExtensions, which is currently [web.js, js, ts ,web.tsx, tsx, json, web.jsx, jsx, node].

[markcellus]

@ofekshalom I created cookie-store. The API is slightly different from this one and more in line with the HTML spec but it has TypeScript support and its been working well for me so far. 👍