Provide better experience for using lodash in TypeScript

[stabai]

trafficstars

In lots of TypeScript interface .d.ts files around the internet, you see this sort of pattern:

import _ = require("../index");

Unfortunately, Deno is unable to read these because it requires file extensions on imported modules (it expects to see ../index.d.ts). This means that lots of typings are unusable in Deno, while perfectly good in most other engines.

Because the typings for lodash do this, I had an incredibly hard time finding a way to include lodash with correct typings in Deno. Since lodash is such a popular library, I was shocked to see how difficult this was.

One might expect this to work:

// @deno-types="https://esm.sh/@types/[email protected]/index.d.ts?target=deno"
import lodash from "https://esm.sh/[email protected]/lodash.js?target=deno";

But it will simply confuse the engine and give an error:

error: Import 'https://esm.sh/@types/[email protected]/index' failed: 500 Internal Server Error
    at https://esm.sh/@types/[email protected]/common/number.d.ts:1:20

Using lodash without typings severely limits its usefulness, because the compiler won't understand things like the isNil type guard.

Failed strategies

• Use https://deno.land/x/lodash
  • Works, but no typings
  • Note: This option is displayed prominently on the deno.land/x homepage, but it provides no guidance on how to use it with Deno at all
• Use https://deno.land/x/deno_lodash
  • Works, but no typings
• Use @deno-types from esm.sh (with or without ?target=deno options): https://esm.sh/@types/lodash/index.d.ts
  • Error reading types
• Use @deno-types from skypack (without options): https://cdn.skypack.dev/@types/lodash/index.d.ts
  • Error reading types

Successful strategies

• Use @deno-types from skypack (with ?dts options):

// @deno-types="https://cdn.skypack.dev/@types/lodash?dts"
import lodash from "https://cdn.skypack.dev/lodash-es";

• Use https://deno.land/x/deno_ts_lodash
  • Note: This repo appears to be unmaintained and hasn't been touched in over a year

[nayeemrmn]

@ije Any idea what's going on at https://esm.sh/v87/@types/[email protected]/index?

[stabai]

@nayeemrmn I might be misunderstanding what you're looking for, but esm.sh appears to serve that throw statement for any file it can't find (not sure why it's a 500 rather than a 404). It can't find index because the file is actually index.d.ts.

[ije]

i will look into it

[stabai]

A small addendum to my "successful strategies" above: you can use the Skypack version with typings much more simply than what I posted originally. No @deno-types directive is necessary if you just import lodash like so:

import _ from "https://cdn.skypack.dev/lodash?dts";

This gives full functionality as well as TypeScript interfaces very simply. It would probably be nice for this to be documented somewhere discoverable though, to save others from having to go through this investigation work.

[kitsonk]

Where would a better place to document it? https://deno.land/manual/typescript/types#deno-friendly-cdns

[stabai]

I think the https://deno.land/x landing page would be a great place to list other resources like Skypack. I'm not sure about others, but that's generally the first place I look for Deno-compatible libraries.

I would also consider if it makes sense for all of these quirky lodash versions to be removed from deno.land/x. Or at least, if they are hosted on deno.land/x despite being suboptimal solutions, can there be:

1. A list of suggested/supported sources (that can include Skypack sources) for popular libraries
2. A warning on such libraries that provides a more optimal/well-supported/popular source for the same library
3. A way to not feature such library sources so prominently:

Note: I didn't realize that page about Deno-friendly CDNs existed in the documentation. It's entirely possible that this is a me problem rather than a documentation problem, but I would think others probably follow a similar pattern for discovery. 🤷

[kitsonk]

I think the https://deno.land/x landing page would be a great place to list other resources like Skypack.

Well deno.land/x is the third party module registry, versus a place to learn how to use Deno. Could be though that we would link off to parts of the manual about using 3rd party modules, maybe specifically "if you are looking to use an existing npm package under Deno..."

I would also consider if it makes sense for all of these quirky lodash versions to be removed from deno.land/x.

That sort of runs contrary to the intent of deno.land/x, where it is up to the community to publish modules. We are currently working on dramatically improving it. The list sorted by GitHub stars is not really a good way of prioritising the usefulness of packages in Deno. We are re-working the scoring and here is a current priority list based on actual popular usage in Deno. We hope to get it on the page very soon. As you can see, it gives you a totally different view of 3rd party modules for Deno.

Note: I didn't realize that page about Deno-friendly CDNs existed in the documentation. It's entirely possible that this is a me problem rather than a documentation problem, but I would think others probably follow a similar pattern for discovery. 🤷

Also there is: https://deno.land/manual/node/cdns. It certainly about discovery. It is also sort of the low friction nature of things too. You just import a URL, it is just really hard to tell what URL gives you a good experience or not.

[stabai]

That all makes sense, thanks for the attention!

Well deno.land/x is the third party module registry, versus a place to learn how to use Deno.

I guess my point was that, despite having read a lot of the Deno documentation multiple times, I had still barely ever seen any host besides deno.land used for imports in Deno. It would be nice if there were more ways to make people aware of these other options without having to know exactly where to look. Part of the reason I never read the "Packages from CDNs" page is because the connotation I took from that title was that it would be about optimizing serving speed. A name like "Package repositories" might have made me think it would be more helpful for my case.

A few other possibly-related documentation pages where I'd have been much more likely to see this:

• https://deno.land/manual/linking_to_external_code
• https://deno.land/manual/examples/import_export
• https://deno.land/manual/getting_started/first_steps (or somewhere else in the Getting Started section)

But again, thanks for the attention on this. Finding the right packages is hard, and I was just surprised by how long it took me to figure this out, but it is much better documented than I realized and works great. I'm just adding all of these thoughts on the chance that it's helpful for any future changes.

[kitsonk]

Yes, don't get me wrong, it is something we need to address. Thanks for giving some feedback and thoughts. We have been chatting about this internally.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.