Duplicate library names trample on each other.

[vsmenon]

We currently use the filename as the library name. If we have two library files with the same name, e.g.,:

foo/baz.dart
bar/baz.dart

we can get weird behavior - both libraries will be defined in the module 'baz'.

[jmesserly]

ouch!

I wonder, can we preserve the path structure? That would at least fix the file collision issue. (Global name collision in the JS scope is another issue)

[vsmenon]

Here's a CL to complain at runtime when we hit a conflict:
https://codereview.chromium.org/1145243013/

[vsmenon]

A couple options:

1. Use the name from the library directive. This is intended to be unique per the spec, but not an error. We could require it. (Dart2js complains on collision)
2. Use the path structure. Relative to which path though? We could have multiple entry points. Relative to packages?

[leafpetersen]

Are library names really supposed to be globally unique? That seems completely unscalable. I thought the restriction was just that you can't import two libraries with the same name.

[vsmenon]

Section 18 of the spec suggests they should be unique, but are not required to be.

[leafpetersen]

My reading of 18 is that the libraries that make up the surface area of a package are intended to be globally unique, but not libraries that are internal to a package (unless there is wording that I'm missing). I really don't think we can expect that only one package ever defines any given library name unless the convention becomes something like the java package convention. As it stands, I'd bet there are lots of packages that define an internal "util" library (for example), and as soon as you include two such packages, library names aren't unique anymore, and there's nothing you can do about it except rewrite other people's code. I guess we could go with the assumption that library names are unique within a package, and then qualify by package?

[vsmenon]

Good point. What every we do, qualifying by package seems like a good idea. We'd get this with @jmesserly's suggestion to use the path structure. I like that from a debugging standpoint - it's easy to map the library name to the file in devtools.

I can try this out. Suggestions for a separator char? E.g.,

packages/foo/src/foo.dart

maps to name

"packages__foo__src__foo"

?

[leafpetersen]

What about actually reifying the path structure into javascript objects? That is, using something like packages.foo.src.foo ? I'm presuming all of this relies on introducing short local names for readability?

[jmesserly]

stepping back a bit ... in ES6 modules, there's no notion of the module's self-name.
http://www.2ality.com/2014/09/es6-modules-final.html

So "packages__foo__src__foo" is not a name we'd ever need to appear in generated code. Instead it would be an import of 'packages/foo/src/foo'.

As to how we backport ES6 modules to ES5, that's a valid question, and I think it would depend on the target. e.g. if targeting Closure, it has a module system. (example of usage here https://github.com/google/closure-library/blob/master/closure/goog/array/array.js#L22). If targeting node.js, same story. In browser, there are a few different options, I'm not 100% sure yet which one would work best.

All of this will require the ability to determine if our ideal top-level name choices are colliding, and if they are, back off and invent an "import prefix" ... this is similar in Dart, to how we import things under whatever name names sense at the import site.

[jmesserly]

Anyway since we're hitting this now, it's probably time to invest in modules (#34). Otherwise we can spend a lot of time coming up with a solution that we have to reconsider as soon as we have modules. Basically, the reason we're grappling this is that ES5 was horribly confused about how to organize code outside of a single big JS file. ES6 to the rescue :). Also, now that the future is clear, it's making the current story a bit more clear too, since existing systems have converged on a handful of working module systems that have an upgrade path to ES6.