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

Added support for emitting System.register modules #2840

Merged
merged 25 commits into from
Apr 27, 2015
Merged

Conversation

vladima
Copy link
Contributor

@vladima vladima commented Apr 21, 2015

Brief description: System.register explained

@DanielRosenwasser
Copy link
Member

Would you recommend a commit-by-commit or files-changed review? I'm leaning towards the latter from what I can see.

@danquirk
Copy link
Member

Our current testing of module formats is just to baseline both AMD and CommonJS all the time rather than needing to specify the module format for each test. Should we just start adding this as a 3rd default target? It's not necessarily high value (we don't exactly have a lot of tests that only break in AMD or CommonJS but not both) but it's nice not to have to deal with specifying it if the cost (test runtime, repo size) isn't that much worse.

@vladima
Copy link
Contributor Author

vladima commented Apr 21, 2015

apparently this functionality was dropped at some point - now we always explicitly specify what kind of modules we would like to emit, i.e.here. However it seems to be a valuable thing to always produce baselines for all supported module kinds so we can automatically verify that emit is expected in all supported scenarios - I'm going to file a suggestion to bring this feature back.

* i.e non-exported variable statement 'var x = 1' is hoisted so
* we we emit variable statement 'var' should be dropped.
*/
function isSourceFileLevelDeclarationInSystemExternalModule(node: Node, isExported: boolean): boolean {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

how about isSystemJSHoistableDeclaration or shouldHoist

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed, current name is shouldHoistDeclarationInSystemJsModule

* if we should also export the value after its it changed
* - check if node is a source level declaration to emit it differently,
* i.e non-exported variable statement 'var x = 1' is hoisted so
* we we emit variable statement 'var' should be dropped.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we just split them into two functions, one for hoistable declarations, and one for exported ones.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll keep this function isSourceFileLevelDeclarationInSystemJsModule and add a helper named shouldHoistDeclarationInSystemJsModule that will call this function with isExported = false. There is only one place that invokes isSourceFileLevelDeclarationInSystemJsModule with isExported = true so I don't think it is worth adding one more helper just for this once case

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I really do not like the name. It is too long.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what alternative do you propose?

@mhegazy
Copy link
Contributor

mhegazy commented Apr 24, 2015

👍

vladima added a commit that referenced this pull request Apr 27, 2015
Added support for emitting System.register modules
@vladima vladima merged commit 824808c into master Apr 27, 2015
@vladima vladima deleted the systemModule branch April 27, 2015 16:39
@mhegazy mhegazy mentioned this pull request Apr 27, 2015
@microsoft microsoft locked and limited conversation to collaborators Jun 18, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants