These are chat archives for TypeStrong/atom-typescript

25th
Apr 2015
Basarat Ali Syed
@basarat
Apr 25 2015 01:25
Matt Traynham
@mtraynham
Apr 25 2015 01:54
@basarat do you sleep? :smile:
Basarat Ali Syed
@basarat
Apr 25 2015 01:56
@mtraynham I am having too much fun
Matt Traynham
@mtraynham
Apr 25 2015 02:20
@basarat what time zone are you anyway?
My guess is Australian at some point
Basarat Ali Syed
@basarat
Apr 25 2015 04:09
Yup Australia, Melbourne :)
Matt Traynham
@mtraynham
Apr 25 2015 04:57
Welp, looks like Windows is still fun to use :smile:
Basarat Ali Syed
@basarat
Apr 25 2015 05:45
:)
Nelo Mitranim
@Mitranim
Apr 25 2015 12:23

Is it just me, or has there been a change to the module declaration format in TS over the last 1-2 days? I have declarations like this:

declare module 'firebase' {
  export default: typeof Firebase
}

They worked until yesterday and now atom-ts reports an error: Expression expected. I googled around but no clue so far

Anyone experiencing the same problem?
Matt Traynham
@mtraynham
Apr 25 2015 18:45

Your example confuses me a bit... what is Firebase? Is it a class?
For CommonJs:

declare module 'firebase' {
    export = Firebase;
}

For ES6:

declare module 'firebase' {
    export default Firebase;
}
default is a reserved word, so that may be like what is causing your issue.
It is ok to do:
Nelo Mitranim
@Mitranim
Apr 25 2015 19:14
@mtraynham Yes in that example it's a class, but I get an error regardless of the type used. Here's another example from lib.d.ts for my gulp configuration files
declare module 'gulp' {
  export default any;
}
(the configuration files are written in TS)
In this example I'm getting two errors: Curcular definition of import alias 'default' and Cannot find name 'any'

If I add a colon:

declare module 'gulp' {
  export default: any;
}

Then I'm getting Expression expected

A bit stumped, really.
Like I said, it worked a few days ago
Matt Traynham
@mtraynham
Apr 25 2015 20:19
Well you have to export something that is backed by code :)
Which means that you can't export any.
Nelo Mitranim
@Mitranim
Apr 25 2015 20:20
Hmm I thought the entire point of module declarations is to define a shape of a module "in vacuum"
Matt Traynham
@mtraynham
Apr 25 2015 20:20
it's a type
err any I guess is an interface.
Nelo Mitranim
@Mitranim
Apr 25 2015 20:20
Yes that's why I used export default: any;
The version without : was just following your example to see if this works
Matt Traynham
@mtraynham
Apr 25 2015 20:21
Ok two things
export default any is equivalent to export = any
any is an interface and you are not allowed to export interfaces
Nelo Mitranim
@Mitranim
Apr 25 2015 20:22
Yeah I thought so
Matt Traynham
@mtraynham
Apr 25 2015 20:22
export default: any wont work because default is a reserved property
you can't assign a type to default
Nelo Mitranim
@Mitranim
Apr 25 2015 20:22
Huh then how in the world are you supposed to export something :D
I mean I looked around for definitions
Matt Traynham
@mtraynham
Apr 25 2015 20:23
So what is the shape of Firebase?
Nelo Mitranim
@Mitranim
Apr 25 2015 20:23
But all examples I've seen are for non-default exports
Matt Traynham
@mtraynham
Apr 25 2015 20:23
you said it was a class
Nelo Mitranim
@Mitranim
Apr 25 2015 20:23
^ Let's stick with something simple for now, like any or string since those don't work either
Just in case, do you have a default export somewhere in your own definitions?
Matt Traynham
@mtraynham
Apr 25 2015 20:24
sure, I'll so you an example:
this is a definition file? .d.ts extension?
Nelo Mitranim
@Mitranim
Apr 25 2015 20:24
yep
Matt Traynham
@mtraynham
Apr 25 2015 20:25
Here's an example:
declare module 'User' {
     class User {
        name: string;
        roles: Array<string>;
    }
    export default User;
}
Nelo Mitranim
@Mitranim
Apr 25 2015 20:26
AHA
Matt Traynham
@mtraynham
Apr 25 2015 20:26
:)
Nelo Mitranim
@Mitranim
Apr 25 2015 20:26
So you have to define something in the module to export it!
Dammit why I found no examples
Thanks this works
Matt Traynham
@mtraynham
Apr 25 2015 20:26
so, you can do other things :)
Nelo Mitranim
@Mitranim
Apr 25 2015 20:27
Hmm other things?
Matt Traynham
@mtraynham
Apr 25 2015 20:27
the example I showed above export's the class User
so if I do:
import User from 'User';
I can then call var x: User = new User()
make sense?
Nelo Mitranim
@Mitranim
Apr 25 2015 20:28
You mean in an abstract definition file? Didn't know they support imports
Matt Traynham
@mtraynham
Apr 25 2015 20:28
I mean in a regular ts file
Nelo Mitranim
@Mitranim
Apr 25 2015 20:29
Ah well of course, I would expect it to understand this kind of type information
testing now
Matt Traynham
@mtraynham
Apr 25 2015 20:29
right
so there is a common theme for type definitions with libraries
like angular, where you aren't exporting just a class but a range of functionality
like lodash for example
Nelo Mitranim
@Mitranim
Apr 25 2015 20:31
Yeah and it seems I'll need to import third party definitions like DefinitelyTyped for that
Looking forward to the day when libraries are distributed as .ts so we no longer need that
Matt Traynham
@mtraynham
Apr 25 2015 20:31
it's not soo bad :)
but they have a common theme for exporting
Nelo Mitranim
@Mitranim
Apr 25 2015 20:31
JavaScript, taking 20-30 years to catch up to C
Matt Traynham
@mtraynham
Apr 25 2015 20:31
lol
you'll usually see:
declare var _: _.LoDashStatic; // var declaration of internal

declare module _ { // internal module
     interface LoDashStatic { // interface
}

declare module "lodash" { // external module
     export = _; // exporting our internal declaration
}
where things are written like internal modules, which build up to a single variable, and that single variable is exported on an External module
Nelo Mitranim
@Mitranim
Apr 25 2015 20:35
Well intuitively I'd expect it to mirror the structure of the actual code
This probably reflects how it's written
Matt Traynham
@mtraynham
Apr 25 2015 20:35
which it often does, sort of.
since most code is written in CommonJS syntax, it's the old way.
Nelo Mitranim
@Mitranim
Apr 25 2015 20:36
Pretty understandable, I have a few libraries that use some private classes for utility and export something else
Matt Traynham
@mtraynham
Apr 25 2015 20:36
When you use the reserved word default in that form, you're using ES6 modules
right!
hope that clears up a few things for you :)
Nelo Mitranim
@Mitranim
Apr 25 2015 20:36
Well that project is all TS so I'm using that syntax to match up
Yeah it's been a great help, thanks :D
Matt Traynham
@mtraynham
Apr 25 2015 20:37
by the way, the ES6 module stuff is pretty new and quite a few people have already given loads of feedback to how it works with CommonJS or AMD
so if you find yourself hitting a compiler error for some reason, someone on TypeScript's issues has probably already found it :)
Nelo Mitranim
@Mitranim
Apr 25 2015 20:40
We've been using ES6 modules in production at work for a few weeks already, so I'm sort of familiar with how it works with CommonJS
This problem was about the semantics of module definitions in TypeScript itself
This format predates the ES6 spec I think?
Matt Traynham
@mtraynham
Apr 25 2015 20:41
The default there? Not entirely. Microsoft/TypeScript#2242
Try 2 months
Nelo Mitranim
@Mitranim
Apr 25 2015 20:41
Huh so it's recent
Oh nice document, thanks
Matt Traynham
@mtraynham
Apr 25 2015 20:42
They support CommonJS as well, which is export =
the "old" way.
Nelo Mitranim
@Mitranim
Apr 25 2015 20:42
Yeah luckily I'm done using that :D
babel/register ftw
Matt Traynham
@mtraynham
Apr 25 2015 20:42
:)
you're using jspm?
or just System?
Nelo Mitranim
@Mitranim
Apr 25 2015 20:43
jspm, yeah
Matt Traynham
@mtraynham
Apr 25 2015 20:44
liking it so far? I've been meaning to try it
Nelo Mitranim
@Mitranim
Apr 25 2015 20:44
For me, jspm + System + es6 module semantics had a learning curve
But if you're already familiar with System, jspm is just a CLI for installing packages and bundling, so there's not much to learn
Definitely more useful than bower
It's a lovely workflow, I'm switching all my projects over to jspm + System + ES6 modules
Matt Traynham
@mtraynham
Apr 25 2015 20:45
so do you bundle the project?
or is System just calling for file dependencies at run time?
Nelo Mitranim
@Mitranim
Apr 25 2015 20:46
When in development, I bundle the dependencies and let System import my modules dynamically. When deploying for production, I bundle everything into one file
Matt Traynham
@mtraynham
Apr 25 2015 20:46
interesting
Nelo Mitranim
@Mitranim
Apr 25 2015 20:46
backed by gulp to transpile my files so that System doesn't invoke an on-the-fly transpiler
There's some magic involved
Matt Traynham
@mtraynham
Apr 25 2015 20:47
:) there always is
well thanks for the info!
Nelo Mitranim
@Mitranim
Apr 25 2015 20:47
The first bit of magic is that it doesn't matter if you bundle things or not, they can be imported either way, you just reduce the number of requests
Matt Traynham
@mtraynham
Apr 25 2015 20:47
what about browser caching?
Nelo Mitranim
@Mitranim
Apr 25 2015 20:47
And the second bit of magic is that it doesn't matter if you transpile from ES6, System will invoke the transpiler if needed
Matt Traynham
@mtraynham
Apr 25 2015 20:48
interesting
Nelo Mitranim
@Mitranim
Apr 25 2015 20:48
But of course pre-transpilation and bundling speeds up development and is absolutely required for production
In the end you just include one script tag as always
Matt Traynham
@mtraynham
Apr 25 2015 20:48
gotcha
Nelo Mitranim
@Mitranim
Apr 25 2015 20:48
But you have ES6 module import semantics (implicit async etc)
It's awesome if you're not an angular1 user
if you are, tough luck
Matt Traynham
@mtraynham
Apr 25 2015 20:48
ha
I'm in that bucket...
Nelo Mitranim
@Mitranim
Apr 25 2015 20:49
Because angular1 requires all ng1 modules to be registered synchronously before bootstrapping
So you need to import all your files then bootstrap the app manually
Matt Traynham
@mtraynham
Apr 25 2015 20:49
sort of, you can get away with injecting things into Angular at runtime, but it's a pain
Nelo Mitranim
@Mitranim
Apr 25 2015 20:50
What I ended up doing is I have a "boot" module that imports everything in my application then does this:
angular.element(document).ready(() => {
  angular.bootstrap(document.body, [app.name], {
    strictDi: true
  })
})
Matt Traynham
@mtraynham
Apr 25 2015 20:51
interesting
what is the strictDI param there? denotes everything loaded up front?
Nelo Mitranim
@Mitranim
Apr 25 2015 20:52
It makes angular throw an error if one of your services doesn't have its dependencies (for injection) specified with strings
Like including ng-strict-di next to ng-app="<appname>"
The biggest pain in the ass is that you have to keep some stuff in angular1 services and can't export / import absolutely everything the ES6 way
I'm stoked for Aurelia / Angular2 (whichever goes into beta first) since they don't have that problem
Matt Traynham
@mtraynham
Apr 25 2015 20:57
agreed :)
Basarat Ali Syed
@basarat
Apr 25 2015 22:26
@Mitranim are you still getting compiler errors where there were none previously. Can you try again after updating atom typescript?
I pushed another fix yesterday that might have been causing it : I brought in the compiler sources and forgot to add a few (because I trusted the TS repo's tsconfig.json) : TypeStrong/atom-typescript@7e9b9c5
Nelo Mitranim
@Mitranim
Apr 25 2015 22:31
@basarat Yeah I've updated and still getting that module error, if I edit the files to reproduce the old syntax. At this point I'm not 100% sure it should have worked in the first place, to be honest. After rewriting to match the expected syntax (thanks to @mtraynham), the module definitions work. Maybe the errors weren't being detected previously...
Basarat Ali Syed
@basarat
Apr 25 2015 22:38
@Mitranim these aren't in .d.ts files from definitely typed are they?
Nelo Mitranim
@Mitranim
Apr 25 2015 22:38
no, custom definitions
Basarat Ali Syed
@basarat
Apr 25 2015 22:39
almighty then. I guess its just the language getting stricter (more correct) :rose: :)
Nelo Mitranim
@Mitranim
Apr 25 2015 22:39
:)