-
Notifications
You must be signed in to change notification settings - Fork 3.8k
Closed
Labels
internalExternal contributions not acceptedExternal contributions not accepted
Description
Closure compiler documentation:
The specific steps that we need to take, pulled from the closure documentation:
Migrating Closure modules with named exports
For Closure modules that use named exports we recommend migrating files in place over 3 changes.
- Edit the implementation file to be an ES module that calls
goog.declareModuleIdwith the old Closure module name (i.e. the old argument togoog.module). This should allow other files to continue usinggoog.requireon the Closure namespace. (Be sure to import Closure'sgoog.jsfile rather than use the globalgoogsymbol!) - Edit all ES module files that are using
goog.requireon the module namespace to instead use ESimport. - Remove the call to
goog.declareModuleIdin the migrated file once it is not being referenced by anygoog.moduleorgoog.providefiles.
Reasons to migrate
- (As I understand it) the Typescript compiler cannot pick up and use the correct types for imports in the form of
const {Foo} = goog.require('Blockly.Foo'). - Tsickle assumes that the input files are ES modules.
- Tsickle relies on correct parsing by the typescript compiler, and chokes when the compiler chokes.
- The closure compiler understands ES modules, so in theory this change can be done without involving the typescript compiler--meeting my goal of being able to compiler with the closure compiler up until we've fully debugged our typescript compilation flow.
pavi2410pavi2410
Metadata
Metadata
Assignees
Labels
internalExternal contributions not acceptedExternal contributions not accepted