Transpile JS Modules into goog.modules. #948
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This change unifies the treatment of modules between TypeScript and JavaScript so that both are transpiled to goog.modules.
JS is only ever transpiled by TSC in development mode. In production mode it must be handed unmodified to closure compiler. As such, we make use of a number of constructs that work as expected when executed, but that closure compiler can not read. The clearest example is that we compile goog.declareModuleId to a construct that directly modifies the private goog.loadedModules_ data structure.
JS script transpilation is unchanged by this CL. We consider a JS file a script unless it must be parsed as a module (e.g. it's a module if it has an import or an export, otherwise it is a script). Modules with no imports or exports are encouraged to add `export {};` to unambiguously parse as modules.
One known limitation of this change is that re-exports of mutable exports are not themselves mutable. We could potentially support this by emitting getters when re-exporting in dev mode, but given that mutable exports are forbidden by the style guide and not widely used in third_party code at this time we're punting on that for now.
Downstreaming as cl/222802097
mprobst
approved these changes
Nov 28, 2018
|
(actual downstreaming looks like it will be cl/223155300, cl/222802097 will be what hooks it up with tsc_wrapped) |
alexeagle
pushed a commit
to bazelbuild/rules_typescript
that referenced
this pull request
Dec 4, 2018
…lver that is significantly simpler than TypeScript's module resolver. Specifically, it does no inference and does not look at the file system. It accepts relative path imports, and workspace-rooted import paths (i.e. google3/foo/bar.js). This change builds on top of angular/tsickle#948 PiperOrigin-RevId: 223763346
alexeagle
pushed a commit
to alexeagle/rules_nodejs
that referenced
this pull request
Oct 17, 2020
…lver that is significantly simpler than TypeScript's module resolver. Specifically, it does no inference and does not look at the file system. It accepts relative path imports, and workspace-rooted import paths (i.e. google3/foo/bar.js). This change builds on top of angular/tsickle#948 PiperOrigin-RevId: 223763346
alexeagle
pushed a commit
to alexeagle/rules_nodejs
that referenced
this pull request
Oct 18, 2020
…lver that is significantly simpler than TypeScript's module resolver. Specifically, it does no inference and does not look at the file system. It accepts relative path imports, and workspace-rooted import paths (i.e. google3/foo/bar.js). This change builds on top of angular/tsickle#948 PiperOrigin-RevId: 223763346
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This change unifies the treatment of modules between TypeScript and JavaScript so that both are transpiled to goog.modules.
JS is only ever transpiled by TSC in development mode. In production mode it must be handed unmodified to closure compiler. As such, we make use of a number of constructs that work as expected when executed, but that closure compiler can not read. The clearest example is that we compile goog.declareModuleId to a construct that directly modifies the private goog.loadedModules_ data structure.
JS script transpilation is unchanged by this CL. We consider a JS file a script unless it must be parsed as a module (e.g. it's a module if it has an import or an export, otherwise it is a script). Modules with no imports or exports are encouraged to add
export {};to unambiguously parse as modules.One known limitation of this change is that re-exports of mutable exports are not themselves mutable. We could potentially support this by emitting getters when re-exporting in dev mode, but given that mutable exports are forbidden by the style guide and not widely used in third_party code at this time we're punting on that for now.
Downstreaming as cl/222802097