Skip to content
This repository has been archived by the owner on Oct 20, 2022. It is now read-only.

Test Closure Compiler behavior with different extern fomats #22

Open
jmmk opened this issue Jul 2, 2016 · 4 comments
Open

Test Closure Compiler behavior with different extern fomats #22

jmmk opened this issue Jul 2, 2016 · 4 comments

Comments

@jmmk
Copy link
Owner

jmmk commented Jul 2, 2016

Looking at the externs contained in https://github.com/google/closure-compiler/tree/master/contrib/externs, it seems like only the top-level namespace and the prototypes are defined. Is it actually necessary to recurse into everything?

e.g.

var namespace = {
    property: {
        anotherProperty: 1234
    }
};

If we use namespace.property.anotherProperty inside a program, do we need to provide externs for namespace.property.anotherProperty, or does namespace.property suffice?

@jmmk
Copy link
Owner Author

jmmk commented Jul 2, 2016

https://github.com/google/closure-compiler/blob/master/contrib/externs/maps/google_maps_api_v3.js also includes enum properties. Is this necessary or is it an optimization? If an optimization, what does it do/allow?

@jmmk
Copy link
Owner Author

jmmk commented Jul 30, 2016

Ideas for how to test this issue (#22) and others related to Closure Compiler behavior (#10, #9, #1):

@jmmk jmmk changed the title Are nested properties even necessary? Test Closure Compiler behavior with different extern fomats Apr 9, 2017
@jmmk
Copy link
Owner Author

jmmk commented Apr 9, 2017

Things to test:

  • Are nested properties necessary
  • Do we need to define the prototype, or can we just specify properties of an object
  • Do we even have to make the distinction between a function and an object

@jmmk
Copy link
Owner Author

jmmk commented Nov 11, 2018

Probably easier to run on the command line: closure-compiler --compilation_level ADVANCED [--externs externs.js,] --js file.js[,] [--js_output_file output.js]

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant