4 ms·

> How to best handle styled-components/material-ui/other library in ts environment? I’m using Blueprint 3 in TS environment and it’s really nice to get feedbac

> How to best handle styled-components/material-ui/other library in ts environment? I’m using Blueprint 3 in TS environment and it’s really nice to get feedback about, say, wrong props passed to one of its styled components right as you type. > My experience with typescript has been cumbersome with these libraries. A lot of time is spent figuring out what ”types” to return. I find this very difficult in most cases and not fun at all. Whether your code is statically typed or not, you generally have to be aware of which data structure goes where—otherwise it’s easy to break things. When code is statically typed, most things break at compile time, enabling your IDE to give immediate feedback. I find the flow much more pleasant if I don’t have to hunt down runtime errors resulting from using a library (BP3 or anything else) in a wrong way. There is some upfront effort in specifying types explicitly where compiler can’t figure it out or does so mistakenly; how fun that is might depend on your personality and established habits. In addition, I believe it heavily depends on tooling—I like using TS in VS Code environment, but TS with Vim (which I’ve been using for many years) was somewhat of a hell. Once in a while I come across an obscure library without TS typings, in which case I would generally provide a `.d.ts` file for it, starting with a catch-all `any` type for its exports, later potentially specifying it further if useful and feasible. This is by far the least fun part.

shroom 6y ago
Oh thanks! Yes my "problem" is mostly around what types to return or rather how to find them. To be aware that separate types package must be installed is definitely something to get into habit. I wasn't aware of the `.d.ts` files. It sounds a lot like what I was looking for! Thanks again for your feedback and help :-)
- strogonoff 6y ago
  If finding types is especially difficult, it may depend on a particular library (poorly documented types) and on the tooling you use (e.g., VS Code allows to quickly jump to definition/implementation/etc. on any imported class or component in your code, which often takes you to the place in that library where you can find out which types you need and where to import them from; it was a bigger pain in Vim). By the way, keep in mind that it is often unnecessary to specify types explicitly because TS can infer them from context. I used to specify way too many types when I was initially learning TS.
- bavell 6y ago
  Most of the time you can just `npm install -D @types/package-name` to get the types for that package. E.g. `npm i -D @types/lodash`
  - strogonoff 6y ago
    As to the remaining cases, a custom definitions file is unfortunately required to avoid compile-time errors.
  - WorldMaker 6y ago
    I find you generally want the @types/ dependencies in the same package.json array as the related dependency (ie, if lodash is a devDependency then `npm i -D` away, but if it is a proper dependency it generally makes sense to `npm i @types/lodash`). Different project's mileage will of course vary, but it makes it easier for downstream dependencies.
rikroots 6y ago
> Once in a while I come across an obscure library without TS typings, in which case I would generally provide a `.d.ts` file for it, starting with a catch-all `any` type for its exports, later potentially specifying it further if useful and feasible. This is by far the least fun part. If you have time, I have a question. Note that my professional exposure to Typescript projects is minimal. I've built a Javascript library which lives in GitHub, NPM, etc (I won't spam the link). It is entirely module-based Javascript. My understanding is that while Typescript-based projects can use non-TS JS libraries (because TS is a superset of JS), using that library would require more work - initial code, and maintenance - than using an equivalent library either written in TS, or one that includes a TS Declaration File. If yes to the above, then - given that I'm serious about my library and want other people to use it if it meets their project needs - I assume I need to write a .d.ts Declaration File (or maybe several?) for it. - How much initial work are we talking here: weeks? Months? - After the initial work, how much additional work is required to maintain the .d.ts files(s)? - How much damage could a poorly written .d.ts file do to a library? - I've seen the Microsoft documentation[1] and ... this looks like a massive amount of work for my library. I know how popular and useful TS has become but, at the end of the day, would I be wasting my time doing what would be, for me, unpaid work? [1] https://www.typescriptlang.org/docs/handbook/declaration-files/introduction.html https://www.typescriptlang.org/docs/handbook/declaration-fil...
- WorldMaker 6y ago
  I've written a lot of .d.ts files, hopefully I can help. > My understanding is that while Typescript-based projects can use non-TS JS libraries (because TS is a superset of JS), using that library would require more work - initial code, and maintenance - than using an equivalent library either written in TS, or one that includes a TS Declaration File. More work, yes, but often not a lot of it depending on need. (You can just tell Typescript some modules are `any` and treat them as a black box.) It's not so much "more work" as it is "less confidence". If you are looking for trust from TS developers in your library, a TS Declaration is API documentation directly in their IDE that does basic sanity/usage checks for them. > How much initial work are we talking here: weeks? Months? I find it is usually in the order of hours. The variables are the size of your library and in particular its external API surface and how well your API is already documented. A .d.ts file is just another sort of API documentation. If you've got good JSDOC comments, for instance, that does a lot of the work already. In some cases you can get a .d.ts file for "free" from Typescript if you follow a couple patterns in your JSDOC comments and run Typescript on your JS files. (It might also give you errors where your code doesn't agree with type hints in your JSDOC comments, which you may or may not find useful to discover potential bugs or edge cases in your code.) > After the initial work, how much additional work is required to maintain the .d.ts files(s)? It depends on your API changes, especially breaking changes. I've told a number of projects to feel free to @ me when they make API changes and I'll PR a .d.ts update and it's rarely more than a couple minutes to look at what their breaking API changes are and what update what needs to be updated. > How much damage could a poorly written .d.ts file do to a library? Again, it's mostly a "loss of confidence" style issue. A poorly written .d.ts isn't going to stop a Typescript user from using your library, it's mostly at worst just going to get in their way and they have to use an escape valve (such as a cast to `any` telling Typescript to get out of the way) and it is no worse than having no .d.ts. Again, if it helps to think of it as API documentation: a bad .d.ts file is like finding an out of date API document for an old version of the API. It can still offer sign posts to what the expected API is supposed to be, it just requires the user of the library to distrust that documentation and either read the source directly or find other documentation sources (StackOverflow or example code from other users, for example). > I've seen the Microsoft documentation[1] and ... this looks like a massive amount of work for my library. I know how popular and useful TS has become but, at the end of the day, would I be wasting my time doing what would be, for me, unpaid work? As with any open source work it is a trade-off and you need to make that determination based on what you are comfortable with maintaining. That's why whenever I've written .d.ts files for libraries I don't maintain, I make sure to explain the maintenance effort, often volunteer to try to do my best to keep it maintained, and also realize and respect that not every library wants to maintain their own .d.ts. It's also why you don't necessarily need to build the types yourself if you aren't (yet) comfortable learning Typescript or switching to Typescript. (Aside: I find that curiosity in adding your own .d.ts file is often a baby step for learning where Typescript helps you in making a better library, and some of the projects I first helped maintained a .d.ts eventually learned and switched to Typescript themselves.) If you can find a user of your library that uses Typescript, they may already have a partial type definition you can start from and/or be willing to help you write/maintain the type definitions. There is a central repository called DefinitelyTyped that happily maintains shared type definitions for a large number of libraries that don't intend to or cannot own and/or maintain their own type definitions. It publishes to an @types/ organization on npm. Your library may already be on there if you have enough users. In that case you also already have a path to starting with something someone else wrote, and GitHub username's to contact and reach out for additional help. If you aren't already in DefinitelyTyped and don't know specific users of your library that use Typescript who could help contribute, there are Definitions Wanted tags in DT's Issue tracker on GitHub and sometimes you can find help from DT's large number of contributors. Hope that helps.

shroom 6y ago

Oh thanks! Yes my "problem" is mostly around what types to return or rather how to find them. To be aware that separate types package must be installed is definitely something to get into habit. I wasn't aware of the `.d.ts` files. It sounds a lot like what I was looking for! Thanks again for your feedback and help :-)

strogonoff 6y ago
If finding types is especially difficult, it may depend on a particular library (poorly documented types) and on the tooling you use (e.g., VS Code allows to quickly jump to definition/implementation/etc. on any imported class or component in your code, which often takes you to the place in that library where you can find out which types you need and where to import them from; it was a bigger pain in Vim). By the way, keep in mind that it is often unnecessary to specify types explicitly because TS can infer them from context. I used to specify way too many types when I was initially learning TS.
bavell 6y ago
Most of the time you can just `npm install -D @types/package-name` to get the types for that package. E.g. `npm i -D @types/lodash`
- strogonoff 6y ago
  As to the remaining cases, a custom definitions file is unfortunately required to avoid compile-time errors.
- WorldMaker 6y ago
  I find you generally want the @types/ dependencies in the same package.json array as the related dependency (ie, if lodash is a devDependency then `npm i -D` away, but if it is a proper dependency it generally makes sense to `npm i @types/lodash`). Different project's mileage will of course vary, but it makes it easier for downstream dependencies.

rikroots 6y ago

> Once in a while I come across an obscure library without TS typings, in which case I would generally provide a `.d.ts` file for it, starting with a catch-all `any` type for its exports, later potentially specifying it further if useful and feasible. This is by far the least fun part. If you have time, I have a question. Note that my professional exposure to Typescript projects is minimal. I've built a Javascript library which lives in GitHub, NPM, etc (I won't spam the link). It is entirely module-based Javascript. My understanding is that while Typescript-based projects can use non-TS JS libraries (because TS is a superset of JS), using that library would require more work - initial code, and maintenance - than using an equivalent library either written in TS, or one that includes a TS Declaration File. If yes to the above, then - given that I'm serious about my library and want other people to use it if it meets their project needs - I assume I need to write a .d.ts Declaration File (or maybe several?) for it. - How much initial work are we talking here: weeks? Months? - After the initial work, how much additional work is required to maintain the .d.ts files(s)? - How much damage could a poorly written .d.ts file do to a library? - I've seen the Microsoft documentation[1] and ... this looks like a massive amount of work for my library. I know how popular and useful TS has become but, at the end of the day, would I be wasting my time doing what would be, for me, unpaid work? [1] https://www.typescriptlang.org/docs/handbook/declaration-files/introduction.html https://www.typescriptlang.org/docs/handbook/declaration-fil...

WorldMaker 6y ago
I've written a lot of .d.ts files, hopefully I can help. > My understanding is that while Typescript-based projects can use non-TS JS libraries (because TS is a superset of JS), using that library would require more work - initial code, and maintenance - than using an equivalent library either written in TS, or one that includes a TS Declaration File. More work, yes, but often not a lot of it depending on need. (You can just tell Typescript some modules are `any` and treat them as a black box.) It's not so much "more work" as it is "less confidence". If you are looking for trust from TS developers in your library, a TS Declaration is API documentation directly in their IDE that does basic sanity/usage checks for them. > How much initial work are we talking here: weeks? Months? I find it is usually in the order of hours. The variables are the size of your library and in particular its external API surface and how well your API is already documented. A .d.ts file is just another sort of API documentation. If you've got good JSDOC comments, for instance, that does a lot of the work already. In some cases you can get a .d.ts file for "free" from Typescript if you follow a couple patterns in your JSDOC comments and run Typescript on your JS files. (It might also give you errors where your code doesn't agree with type hints in your JSDOC comments, which you may or may not find useful to discover potential bugs or edge cases in your code.) > After the initial work, how much additional work is required to maintain the .d.ts files(s)? It depends on your API changes, especially breaking changes. I've told a number of projects to feel free to @ me when they make API changes and I'll PR a .d.ts update and it's rarely more than a couple minutes to look at what their breaking API changes are and what update what needs to be updated. > How much damage could a poorly written .d.ts file do to a library? Again, it's mostly a "loss of confidence" style issue. A poorly written .d.ts isn't going to stop a Typescript user from using your library, it's mostly at worst just going to get in their way and they have to use an escape valve (such as a cast to `any` telling Typescript to get out of the way) and it is no worse than having no .d.ts. Again, if it helps to think of it as API documentation: a bad .d.ts file is like finding an out of date API document for an old version of the API. It can still offer sign posts to what the expected API is supposed to be, it just requires the user of the library to distrust that documentation and either read the source directly or find other documentation sources (StackOverflow or example code from other users, for example). > I've seen the Microsoft documentation[1] and ... this looks like a massive amount of work for my library. I know how popular and useful TS has become but, at the end of the day, would I be wasting my time doing what would be, for me, unpaid work? As with any open source work it is a trade-off and you need to make that determination based on what you are comfortable with maintaining. That's why whenever I've written .d.ts files for libraries I don't maintain, I make sure to explain the maintenance effort, often volunteer to try to do my best to keep it maintained, and also realize and respect that not every library wants to maintain their own .d.ts. It's also why you don't necessarily need to build the types yourself if you aren't (yet) comfortable learning Typescript or switching to Typescript. (Aside: I find that curiosity in adding your own .d.ts file is often a baby step for learning where Typescript helps you in making a better library, and some of the projects I first helped maintained a .d.ts eventually learned and switched to Typescript themselves.) If you can find a user of your library that uses Typescript, they may already have a partial type definition you can start from and/or be willing to help you write/maintain the type definitions. There is a central repository called DefinitelyTyped that happily maintains shared type definitions for a large number of libraries that don't intend to or cannot own and/or maintain their own type definitions. It publishes to an @types/ organization on npm. Your library may already be on there if you have enough users. In that case you also already have a path to starting with something someone else wrote, and GitHub username's to contact and reach out for additional help. If you aren't already in DefinitelyTyped and don't know specific users of your library that use Typescript who could help contribute, there are Definitions Wanted tags in DT's Issue tracker on GitHub and sometimes you can find help from DT's large number of contributors. Hope that helps.