Why the syntax for internal module is not compatible with the syntax for external module ?

Topics: Language Specification
Mar 13, 2014 at 11:30 AM

I think a problem most newcomer run into is that you have to choose between organizing your code with internal module or external module, and because the syntax is not compatible, if you change your mind later your have to rewrite most of your code.

Also, i have noticed both AMD and Require.JS have develeloped bunding tools (require.JS optimiser or browserify) to merge all the files into a big one, like the internal modules do.

So I was wondering, what is the purpose of internal modules (beside confusing people ...), why not keep only external module and have people do the merging using these tools if they want to.

I feel there must be some use for internal module but i have not catched it yet ...
Mar 13, 2014 at 7:33 PM
I would recommend starting here https://typescript.codeplex.com/wikipage?title=Modules%20in%20TypeScript

The purpose is ultimately because of the 2 very different styles of module loading that JavaScript commonly uses.
Mar 14, 2014 at 9:36 AM
I did read the module tutorial before posting here ...

I understand this complexity comes from Javascript, that got many different ways of achieving modularization :
  • bundling
  • Require.JS (with or without r.js optimizer for bundling)
  • Common.JS (with or without browserify for bundling).
This seems to confuse javascript folks as they are many blogs on the subject ("why choose X over Y").

However, I hope TypeScript would bring some kind of clarification here, which it didn't, as you still have to choose between internal or external module early in your project, and if you made the wrong choice, incompatible syntax make the change difficult.
Mar 14, 2014 at 7:48 PM
Because TypeScript is meant to be a superset of JavaScript and capable of expressing its many different patterns it would be very difficult if not impossible to create a single module syntax to express how differently JavaScript modules can work. In addition, there needs to remain room in the language design to align with future JavaScript versions (specifically ES6 in the near future) so we must be mindful of 'using up' too many syntax options early on. How do you envision a solution looking?