Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can't find proper default variable export syntax #237

Closed
Jaeiya opened this issue Apr 6, 2015 · 15 comments
Closed

Can't find proper default variable export syntax #237

Jaeiya opened this issue Apr 6, 2015 · 15 comments

Comments

@Jaeiya
Copy link

Jaeiya commented Apr 6, 2015

Since the update from 1.10 to 2.6 (just after the switch to TypeScript 1.5) every d.ts file needs to have a default export. I haven't read the ES6 spec, but I assume all modules have to have a default export now.

This is all well and good when exporting my own classes, but when using 3rd party libraries, this becomes difficult. Here is a snippet of JQuery d.ts code.

declare var $: JQueryStatic;
declare module "jquery" {
    export = $;
}

Before the update, this code worked just fine and didn't produce any issues, but now I need a default export. The only syntactically correct way that I got to work was the following:

declare var $: JQueryStatic;
declare module "jquery" {
    export default $;
}

This produces incorrect code output:

// FROM
import $ from 'jquery';
var obj = $(ev.srcElement)

// TO
var jquery_1 = require('jquery');
var obj = jquery_1.default(ev.srcElement)

Clearly jQuery does not have a static default method, but even if it did, this is clearly not the expected behavior. Not to mention the $ was not preserved at all. Please let me know how I can declare a default export variable. I have done about an hour of searching for this syntax and cannot find it. Or perhaps I'm going about it the wrong way?

Anyway, thanks in advance.

@Jaeiya Jaeiya changed the title Can't find proper default export syntax Can't find proper default variable export syntax Apr 6, 2015
@csnover
Copy link
Member

csnover commented Apr 7, 2015

but now I need a default export.

What makes you think that?

@Jaeiya
Copy link
Author

Jaeiya commented Apr 7, 2015

Because the compiler won't emit the file without a default export and the import is marked as an error.
ss 2015-04-06 at 07 23 48

@csnover
Copy link
Member

csnover commented Apr 7, 2015

Emit what file? d.ts files don’t generate emitted code.

@Jaeiya
Copy link
Author

Jaeiya commented Apr 7, 2015

Why would I emit a jquery.d.ts file?
I'm using jQuery as an import in a normal TS file, which is clearly demonstrated in the screen shot above, as well as the code snippets I posted in the OP.

@csnover
Copy link
Member

csnover commented Apr 7, 2015

You can’t use the ES6 import syntax to import legacy AMD/CJS module defaults, you must continue to use the import $ = require('jquery'); syntax. import foo from 'foo' will work only for ES6 default exports because they don’t work the same (in ES6 it’s just syntactic sugar for referencing the default property of the imported module).

@csnover csnover closed this as completed Apr 7, 2015
@csnover
Copy link
Member

csnover commented Apr 7, 2015

In the long ticket about ES modules in the TypeScript repository, the gist is here: microsoft/TypeScript#2242 (comment)

@Jaeiya
Copy link
Author

Jaeiya commented Apr 7, 2015

Well that was a lot of reading.

It looks as though all d.ts files that are referenced, have to use the require syntax. You said "legacy" which to me implies a different way to write the definitions in such a way that we could use the ES6 syntax, but from the comment you linked, it appears modules that are not actual modules (just definitions) must be referenced with the "require" syntax. Correct?

Hopefully that's not too confusing haha. Anyway, thanks for the quick response. I wish there was a more specific case example of when to use that module syntax.

@basarat
Copy link
Member

basarat commented Apr 7, 2015

FWIW you can do full imports which is what I've been doing, this is same as commonjs/amd version:

import * as $ from "jquery";

and even partial ones

import {extend} from "jquery"; 

The guidance is to no longer use import/require ... although you can.

@Jaeiya
Copy link
Author

Jaeiya commented Apr 7, 2015

Thank you @basarat, that's the answer I was looking for.

@unional
Copy link
Contributor

unional commented Nov 14, 2015

You can import amd/cjs with import _ from 'lodash'; (I'm using jspm). But atom-typescript still flagging it as error. Will (or how will) it be fixed?

@basarat
Copy link
Member

basarat commented Nov 14, 2015

But atom-typescript still flagging it as error

@unional Not an error in atom-ts. Track in Microsoft/TypeScript 🌹

@unional
Copy link
Contributor

unional commented Nov 14, 2015

Thank! Found the thread: microsoft/TypeScript#5285

@MUMARA
Copy link

MUMARA commented Apr 14, 2016

ggh

@pk-developer
Copy link

pk-developer commented Jan 20, 2019

screen shot 2019-01-20 at 10 03 00
screen shot 2019-01-20 at 10 04 08

Please import the jquery file in index.html and then use 'declare var $: any' in the component where you want to use the '$'

@lierdakil
Copy link
Collaborator

@pk-developer, please, for the love of all that is holy, do no such thing.

First of all, this issue is more than 3 years old and have been resolved many times over. What you're doing here is necroposting at its worst.

Secondly, never use any in TypeScript code if you can avoid it -- it opens gaping wounds in the type system.

Thirdly, why on earth would you want to use jQuery in 2019? Almost all of what it is supposed to do has been implemented in browser APIs (often better).

Fourthly, why on earth would you want to use jQuery with React? It's a great way to break a lot of stuff and get almost nothing in return.

Finally, if you're adamant about using jQuery with Webpack or other bundler, just use the npm module and DefinitelyTyped typings:

npm i --save jquery @types/jquery

(note: it's usually considered bad form including @types definitions in regular dependencies, I'm only doing this here for the sake of brevity; consider adding those to devDependencies instead -- e.g. with --save-dev)

Hopefully, this rant is somewhat educational to someone.

I'm locking this issue.

@TypeStrong TypeStrong locked as resolved and limited conversation to collaborators Jan 20, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants