Compile without `--module` about grunt-ts HOT 11 CLOSED

Don't specify the module key. It will default to amd at the moment : https://github.com/basarat/grunt-ts/blob/master/tasks/ts.ts#L579

from grunt-ts.

Don't specify the module key. It will default to amd at the moment

I think you misunderstand - that's the problem I'm pointing out: it defaults to --module AMD with no way to compile without the --module switch at all. Not everything is a module.

from grunt-ts.

no way to compile without the --module switch at all. . Not everything is a module.

The flag has absolutely no effect on the generated code if you use code that doesn't export anything at the root level of your file.

If however you do a root level export starting with TS 0.9 this compiler flag is required.

If you are unclear of what I mean by root level export I did a video on the subject : http://www.youtube.com/watch?v=KDrWLMUY0R0&hd=1

Hope this helps. I am sure there isn't any reason why your code generation will be different if you do not specify the module flag.

from grunt-ts.

The flag has absolutely no effect on the generated code if you use code that doesn't export anything at the root level of your file.

My entire project consists of root-level exports :-)

And I need the root-level exports as global, root-level symbols - not wrapped in a callback.

You've never needed to use the TypeScript compiler without the --module switch?

I am sure there isn't any reason why your code generation will be different if you do not specify the module flag.

Uhm, yes - completely different... root level exports are provided to you as an object via a callback when built as a module, while in application mode, exported symbols become global variables.

In fact, there is no way to define a global variable in --module mode, short of injecting the members directly into the window object...

from grunt-ts.

If however you do a root level export starting with TS 0.9 this compiler flag is required.

Where did you get that? :-)

Trust me, I have loads of root-level exports, and they are exporting just fine with TS compiler release 0.9.1.1, without the --module switch - and I assure you, the output with the --module switch is very, very different, and not at all suitable for what I'm doing.

I'm not making this stuff up ;-)

from grunt-ts.

Where did you get that? :-)

A file that contains the following will not compile under 0.9.1.1 unless the module flag is specified:

export function foo (){}

http://stackoverflow.com/a/18211690/390330

In fact, there is no way to define a global variable in --module mode,

sure there is. Just do :

function foo (){}

Like I said look at the video : http://www.youtube.com/watch?v=KDrWLMUY0R0&hd=1

from grunt-ts.

A file that contains the following will not compile under 0.9.1.1 unless the module flag is specified

So you keep telling me, and it seems you're right - it doesn't build anymore.

I think I just figured out what's going on here - I've been switching between my laptop and workstation some evenings, and I must have an older version of the compiler on my workstation, because it did build.

I can't use the export directive anymore, and no symbols are accessible across files unless you use export. So I can't build my project anymore.

Would you mind taking a quick look at my project?

Any ideas? I'm completely at a loss here...

from grunt-ts.

Would you mind taking a quick look at my project?

Looks all good. Just delete export whenever you have it at the root level of your file e.g. :

https://github.com/mindplay-dk/petitparser-ts/blob/master/core/context.ts#L8
Change:

/**
 * An immutable parse context.
 */
export class Context {

    private _buffer: string;

to :

/**
 * An immutable parse context.
 */
class Context {

    private _buffer: string;

Then you can access Context from any other file by simply :

/// <reference path="context.ts" />

// Now you can use Context e.g.: 
var foo:Context;

Again, it is covered in the Video : http://www.youtube.com/watch?v=KDrWLMUY0R0&hd=1 watch it already :)

from grunt-ts.

Thanks, I will give it a try, but that's what I was doing originally, and it didn't work - the /// <reference...> tags don't give you access to symbols in other files that weren't exported. Might work if I concatenate all the files into one, like I've been doing. That means no sourcemap however... I guess until they add an include directive or some other way to handle multi-file modules...

For the record, I watched that video several weeks ago :-) ... it explained well what you can do, but I don't think he said you can't use the export directive in application-mode... and since, at the time I could, I just assumed... ;-)

from grunt-ts.

the /// <reference...> tags don't give you access to symbols in other files that weren't exported

If you plan to run on nodejs use commonjs as --module option. It will not wrap your files in a callback.

from grunt-ts.

Gave it a shot with the develop-branch of the TypeScript compiler, and it did build.

Problem is, that's not really what I had in mind at all... When compiling with --out and --module at the same time was still possible, and while export directives without the --module setting was still possible, my plan was this:

1. Build the declaration file (.d.ts) for the library for all top-level exports.
2. Build the library itself as a module

My hope was to use something like this function to extract from the compiled module into local scope, then work with the local scope by referencing the .d.ts file.

I know that may sound "unorthodox", but a lot of JavaScript libraries actually interface with TypeScript in this way - this is how you use e.g. AngularJS, where the .d.ts file declares things like $scope globally, while it is actually only available when it gets injected into a controller/module.

It appears building the library in this way is not going to be possible going forward. (and perhaps never was...)

So the only option is to restructure the entire codebase using explicit import statements everywhere, and expecting the consumer of the library to explicitly import every member. I hate having all this boilerplate, but it seems there is no other way... It's either that, or actually define everything as globals, which would be bad, since there are a lot of three-letter function-names like any() and all() in there, which could easily collide with other globals... My final option is to pre-process the code, which is where I was going, but that means no source-map and cumbersome debugging...

I'm probably better off just waiting until the TypeScript team comes up with some way to support multi-file modules?

from grunt-ts.