Repository navigation
Auto import not working for lodash #29039
Description
TypeScript Version: 3.3.0-dev.20181214
Search Terms:
- auto import
- suggestions / completions
Code
- For a simple js project that has
lodashinstalled undernode_modules - In a blank js file, type:
kebabCase
Expected behavior:
Auto import suggestion to import from lodash returned
Actual behavior:
No suggestion returned
Activity
shayded-exe commentedon Jan 8, 2019
To add to this, it does work once you already have an existing import from lodash in the file. The suggestions don't show up in auto-complete, but it does give a quick fix suggest to add the new method to the existing import from lodash.
aleclarson commentedon Jan 29, 2019
This issue provides a repro: microsoft/vscode#67505
sheetalkamat commentedon Jan 30, 2019
This issue is duplicate of #28773 wherein during completion we don't have knowledge of symbols not in the program and hence no offering in the completions.
aleclarson commentedon Jan 30, 2019
Sheetal Nandi (@sheetalkamat) It's a little surprising that TypeScript doesn't anticipate that a package listed in
dependencieswill eventually be imported by the program. Is this on the roadmap?tnrich commentedon Feb 16, 2019
Even when I am using lodash in a file I still don't get auto-import for it. Here is an image showing it not working:
Lodash is really the only module I see this not working well for.
tnrich commentedon Mar 10, 2019
Any update on this one? This is definitely something I get annoyed by on a near daily basis. I am just continually surprised that this feature which works so well for most other packages doesn't work for the single most popular js library:
Either vscode is doing something wrong or lodash is but it seems really odd that this has been an issue for so long
tnrich commentedon Mar 10, 2019
lodash/lodash#4062
aleclarson commentedon Mar 10, 2019
Thomas Willheim (@tnrich) Do you know of a library (that takes a similar approach for its
.d.tsdefinitions) that works as expected?tnrich commentedon Mar 10, 2019
Alec Larson (@aleclarson) I'm not sure how lodash's .d.ts files are defined. Could you elaborate more?
Do lodash's types get pulled from https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/lodash by default?
aleclarson commentedon Mar 10, 2019
Thomas Willheim (@tnrich) I dove into
@types/lodashto find thatexport = _is the issue.Removing that line is the first step. The problem is that it can't be removed, because
import _ = require('lodash')is probably being used by someone.The other step is to add an
export constline for each Lodash function, though I wonder if something likeexport * from _.LodashStaticis (or should be) possible. Maybeexport as namespace _is supposed to be doing that?Not sure if this is an issue with TypeScript itself, or just
@types/lodash.tnrich commentedon Mar 10, 2019
Hmm thanks for diving in Alec Larson (@aleclarson). I poked around as well but am not super familiar with typescript so felt a bit lost.
I agree that
import _ = require('lodash')is definitely being used by many but there is probably a workaround that allows both.Is there someone we can ask about this? Maybe one of the
@types/lodashmaintainers?Andy (Andrewkraft) (@Andy-MS) AJ Richardson (@aj-r) -- I couldn't find a list of maintainers but it looks like you both have committed a fair amount to the
@types/lodashrepo. Could either of you comment on this issue? Thank you 🙏aj-r commentedon Mar 10, 2019
Yeah lodash is using the namespace 'hack' to support
import _ = require('lodash'). I'm not aware of any other way to support that. But on the other hand, I don't think anyone should be using that style of import with modern Typescript (that doesn't mean they aren't though).tnrich commentedon Mar 11, 2019
AJ Richardson (@aj-r) is the namespace "hack" causing auto-import to fail?
I'm not sure I understand why anyone would be mixing
importandrequire(). That throws lint errors for me.6 remaining items
aleclarson commentedon Mar 11, 2019
tnrich commentedon Mar 11, 2019
Alec Larson (@aleclarson) sweet thanks for that video! After installing
@types/lodash-esit does work for me!It will unfortunately be somewhat complicated to switch over to using lodash-es in all my packages.
I still think the better solution would be to somehow alter the lodash index.d.ts so that auto import works correctly. As long as
import {flatMap} from "lodash";is a valid import statement it seems like there should be a wayaleclarson commentedon Mar 11, 2019
Thomas Willheim (@tnrich) When
export =is used, a CommonJS module is implied, which means named exports (eg:export const) are no longer allowed (since that's an ESM feature). The problem is that named exports are required for auto-import to work.When a user writes the following TypeScript:
..it's equivalent to this JavaScript:
..which is "destructuring" the CommonJS exports of the
lodashpackage.Auto-import can't suggest properties of a CommonJS namespace, because it can't know if the CommonJS package is meant to be used that way.
That being said, you could try opening a new issue with a proposal for
export as namespaceto be used as a hint that auto-import can suggest the namespace's properties. I could see that being a good idea!tnrich commentedon Mar 11, 2019
Alec Larson (@aleclarson) thanks for the detailed explanation. That makes sense to me. Where should I open that new issue? Would that be in the Typescript repo or in a vscode repo?
aleclarson commentedon Mar 11, 2019
Thomas Willheim (@tnrich) No problem! https://github.com/Microsoft/TypeScript/issues/new?template=Feature_request.md
RyanCavanaugh commentedon Mar 19, 2019
Almost every comment in this thread is confused about something and it'd be an hour or more for me to set everything straight here. Please don't read this thread for information.
The primary root cause of this issue is that the JS language service doesn't aggressively include types for packages it can't tell you're using yet, because doing so would be a fairly substantial perf hit for not a lot of gain. Compounding that is that ES6 destructuring imports from CommonJS modules is not a well-defined operation outside of loaders which ignore the spec to make that work.
aleclarson commentedon Mar 20, 2019
Ryan Cavanaugh (@RyanCavanaugh) This comment shows that the actual problem is occurring for a package that is already in use, so what you're saying doesn't seem relevant?
Nevertheless, I want to address your performance claim:
How often does the
dependenciesmap (in package.json) contain a dependency that isn't intended to be used in the package? Never. I don't see how performance is an issue there, and the gain is substantial enough to complain about...Are you suggesting that
@types/lodashshouldn't be using theexport as namespacetrick? To be clear, that would mean alllodashusers must uselodash-esif they want auto-import. I get the feeling that TypeScript doesn't want to encourage CommonJS modules. 😛tnrich commentedon Aug 1, 2019
Lodash auto import still doesn't work in vscode for me. Ryan Cavanaugh (@RyanCavanaugh) could you please suggest some practical steps that we can take to get this fixed?
I don't understand why 80/90% of packages have no issues auto-importing into my project. Seems like lodash is doing something tricky that doesn't quite work. I'd love some more concrete tips that I could try to fix this issue. Thanks!
ricsam commentedon Aug 8, 2019
To just fix the problem I do the following:
and maybe
yarn add lodash@npm:lodash-esIf you want some functionality from lodash that is not part of lodash es, like runInContext, install it under an alias:
tnrich commentedon Sep 9, 2019
Richie (@ricsam) while your suggestion does work brilliantly, it is not compatible with npm. I've run into this issue with it when people try to use my packages:
https://stackoverflow.com/questions/54085943/npm-err-invalid-dependency-type-requested-alias
fhucko commentedon Mar 2, 2023
Import in VSC still not working. I have to write _.something to find the method, then delete "_." and manually write import.