allowSyntheticDefaultImports for modules with no default export not working?

[Etchelon]

Hello, first of all I'm sorry if I don't follow the format you request for the reply, but I've gone mad all evening trying to make the following work and I'm tired, so I'll understand if noone replies:
Angular 2 app
Use moment.js and lodash
Compile AOT and use rollup to bundle.
Everything latest version from npm.

Initially Rollup was complaining about "cannot call a namespace", caused by this:
import * as moment from "moment"
Then I changed to
import moment from "moment"
tsc wouldn't compile until I turned on the "allowSyntheticDefaultImports" flag.
So I did, and it compiled. And Rollup now works!
But,
the generated code for
import moment from "moment"; ... console.log(moment().toDate());
is not what I'd expect, which would be
var moment_1 = require("moment"); ... console.log(moment_1().toDate())
but it actually is
var moment_1 = require("moment"); ... console.log(moment_1.default().toDate())

So I read tons of discussions around the web, and in this repo as well, but I'm pretty confused still, there's no good and definitive documentation... shouldn't the flag I activated prevent the .default() function call on moment??
I'm sorry but I'm not as good with js and modules to understand fully what is going on.
And I find it astonishing that so little people have problems doing a simple thing: using globals from pervasive libraries in an application built with external modules. I want to make modules for the code I write but lodash moment jquery and stuff are always present in the page... I don't want to load lodash as an import as I want to be able to open the dev tools and type _.find(...) in the console, I need it global, and I'm sure I'm not the only one...

Thanks in advance to whoever will help me understand. And I hope using TypeScript will get easier for common scenarios...

TypeScript Version: 2.0.10

[aluanhaddad]

Hi.
This issue probably does not belong here, it spans a lot of scopes and intersects with TypeScript in a few sticky areas.
Here are a few bits of information you may find useful.

And I find it astonishing that so little people have problems doing a simple thing: using globals from pervasive libraries in an application built with external modules.

Well first of all, I think everyone has had trouble migrating from Globals to Modules, it is a massive shift in a lot of ways that are not even immediately obvious.

That said, if you want to use Globals, do not use Modules and vice versa. They do not play nicely together. Globals are not a good thing but they provide convenience. Personally, I think using Modules imposes a substantial syntactic overhead that is worth the price to gain the advantages of script load independence, explicit dependency analysis, automatic loading and bundling, and last but certainly not least improved static analysis.

Synthetic default imports are an interop feature for consuming CommonJS Modules (the format used by most npm packages) from ES Modules. TypeScript does not provide any such interop behavior but it is aware that other components in your toolchain may see fit to do so.
This brings us to allowSyntheticDefaultImports, which is a TypeScript setting that informs the TypeChecker that you are running in an ES Module -> CommonJS Module interop aware environment such as SystemJS. Specifically, the flag is only for the TypeChecker, it does not affect the code that is output in any way shape or form.
Taking this a bit further,

var moment_1 = require("moment");
console.log(moment_1.default().toDate())

Is what the compiler will always emit because the ES Module syntax

import moment from 'moment';

always means exactly one thing: load 'moment' and give me its default export (the export named default) under the name moment.
The truth is that 'moment' does not export anything named default so some tools synthesize one from the somewhat analogous CommonJS module.exports object. Going into full or even reasonable detail would take a very long time and many pages (there is a lot of history) to explain further but the answers are out there.
By setting this very useful flag, you can tell the TypeScript TypeChecker that some other tool is doing this. Otherwise your program could not be properly type checked.

One last point on this, your expected output:

var moment_1 = require("moment"); ... console.log(moment_1().toDate())

would be wrong because the import syntax you used implies access to an export named default but you seem to expect that it vanish. It would be very bad if that were so.

OK, so on to Rollup.
Rollup is a great tool but it has poor direct compatibility with TypeScript because it does a fairly naive analysis that doesn't understand that TypeScript constructs, like interfaces, are compiled away. This causes friction. As of today, the only successful use of Rollup with TypeScript that I have observed involves 1 of 2 paths.

• TypeScript Source -> JavaScript Source -> Rollup -> Bundle
• TypeScript Source -> TypeScript Aware Loader -> TypeScript -> Rollup -> Bundle

rollup-plugin-typescript is rather broken.

Now back to Globals,

I don't want to load lodash as an import as I want to be able to open the dev tools and type _.find(...) in the console, I need it global, and I'm sure I'm not the only one...

As I said, it is hard to use modules, everyone struggles in the beginning, but you generally cannot have it both ways. The browser is plagued by Globals and this can prevent basic software-engineering principles like encapsulation and multi-versioning from working at all. They are convenient but if you use Modules, you must learn to live without them.

Compile AOT and use rollup to bundle.

AOT changes the ballgame in a few fundamental ways.

1. For one thing, it essentially has 0 documentation. What is out there is unofficial, and requests for official documentation have been declined. I made such a request. It was declined.
2. Most of what you know from TypeScript and from JavaScript will fail to work in this mode. (This is entirely and extraordinarily specific to the Angular framework and its particular performance problems and how that framework's developers choose to use their toolkit).
3. This means that your TypeScript and JavaScript tools, IDEs, compilers and so on, will tell you things that are not true. These tools cannot be faulted for this since they do not know what Angular is doing (in the literal sense) and because Angular has not documented or even declared the subset of language features, dramatic semantic changes (such as decorator lowering), and other fundamental aspects of AOT.
4. AOT will eventually have its own tools but right now, you get zip.
5. AOT is, at best, an incredibly crippled subset of TypeScript and JavaScript with very limited expressive power and no quality tools available at this time.

Update
To clarify, I want to add that the Angular team is working hard to build a language service that they can provide to editors such as VS Code so that AOT can be tooled properly.

[Etchelon]

Thank you very much for the prompt and extensive reply.

I understand your points, but I think that for a while I'll adopt this solution (as long as it keeps working):

• load jquery, lodash, moment via script tag, and remove any
  import _ from "lodash" and import moment from "moment". These libraries are a given for me, there's no app I write without them, so I don't really need to encapsulate or bundle anything, they're always bundled in my projects. Modern programming is all done by convention... let's say that having _, $ and moment in window is a kind of convention for me, and many others.
  With regards to benefits in static analysis, dependency analysis etc, I'm sure you're right but from an end user point of view I don't need any of it. I know that I'll always load these libraries before anything else, bundled in a 100kb or so script, end of the story. I'm not obsessed with reaching a "theoretical" optimization of this code, it's external code. My code is another story and that certainly needs to be optimized.
• use the old typings instead of types, since newest .d.ts from @types/lodash make ambient usage of _ no longer possible. In particular, I'll use this typings.json:
  {
  "globalDependencies": {
  "bootstrap": "registry:dt/bootstrap",
  "core-js": "registry:dt/core-js#0.0.0+20160725163759",
  "jasmine": "registry:dt/jasmine#2.2.0+20160621224255",
  "jquery": "registry:dt/jquery#1.10.0+20160929162922",
  "moment": "registry:dt/moment",
  "node": "registry:dt/node#6.0.0+20160909174046",
  "lodash": "registry:dt/lodash#4.14.0+20161110215204",
  "systemjs": "registry:dt/systemjs"
  }
  }
  and ///ref typings/index.d.ts in my boot.ts.

And for the moment I also want to stick with Rollup since, as you said, there's hardly any documentation on how to bundle angular 2 apps (I don't have experience with webpack) and, if I follow their AOT guide, this works fine.

When things change for the better I'll consider moving to external modules more extensively.

[ahnpnl]

hi, I encounter the same issue. When I define "allowSyntheticDefaultImports": true and use import moment from 'moment', I got the error moment_1.default is not a function. Are there any ways to solve this ? If I switch to import * as moment from 'moment' it definitely works but my tests are broken because it says moment is not a function (I'm using Jest)

[mhegazy]

if you are using TS 2.7 or later, use --esModuleInterop

[ahnpnl]

Hi @mhegazy, unfortunately Angular team hasn't released support for 2.7 yet so I temporarily disabled allowSyntheticDefaultImport and it worked for both my test and Angular app

[typescript-bot]

Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.