Qualify library names in packages

lib/src/compiler/code_generator.dart

 // Copyright (c) 2015, the Dart project authors.  Please see the AUTHORS file
 // for details. All rights reserved. Use of this source code is governed by a
 // BSD-style license that can be found in the LICENSE file.
 
 import 'dart:collection' show HashMap, HashSet;
 
 import 'package:analyzer/analyzer.dart' hide ConstantEvaluator;
 import 'package:analyzer/dart/ast/ast.dart' hide ConstantEvaluator;
 import 'package:analyzer/dart/ast/token.dart' show Token, TokenType;
 import 'package:analyzer/dart/element/element.dart';
@@ skipping 3743 matching lines @@
       // is exactly Future/Stream/Iterable.  Handle the subtype case.
       return DynamicTypeImpl.instance;
     }
   }
 }
 
 /// Choose a canonical name from the library element.
 /// This never uses the library's name (the identifier in the `library`
 /// declaration) as it doesn't have any meaningful rules enforced.
 String jsLibraryName(LibraryElement library) {
+  var uri = library.source.uri;
+  if (uri.scheme == 'package') {
+    // Strip the package name.
+    // TODO(vsm): This is not unique if an escaped '/'appears in a filename.
+    // E.g., "foo/bar.dart" and "foo$47bar.dart" would collide.
+    var packageRelativePath = uri.pathSegments.skip(1).join('/');

[Jennifer Messerly, 2016/04/26 22:59:33]

Yeah in general it's not going to be unique.

Also, surely we do not want $47 in our API signatures. :)

I think the problem is `pathToJSIdentifier`... it's not designed to be run
except on the file name.


So last time we had discussed this in:
https://github.com/dart-lang/dev_compiler/issues/504#issuecomment-211561183

... we were going to have non-top-level libs to use some scheme where they're
kind of hidden.

Library name is used in two distinct ways:
A. as a local variable in the module
B. as an export/import member of the module

Only B needs to worry about conflicts.


So something like:

// import
import { unittest, _libs } from 'unittest'

// note: this is a temp, conflicts if any will be automagically handled,
// so we can use any friendly name here. src_matchers would work too.
const matchers = _libs['src/matchers'];


// if we're exporting
export const _libraries = {
  'src/matchers': matchers,
  //...
}

... that would be a generally safe scheme, we only have one special name
(_libraries).

That seems like the route to go for a real fix.

If we just want a quick hack, maybe we could use "_", which would not look too
bad in the code.

+    return pathToJSIdentifier(packageRelativePath);
+  }
+  // TODO(vsm): This is not unique, but we're not in
+  // a package.  We need a mechanism for creating a unique library
+  // name.
   return pathToJSIdentifier(library.source.uri.pathSegments.last);
 }
 
 /// Shorthand for identifier-like property names.
 /// For now, we emit them as strings and the printer restores them to
 /// identifiers if it can.
 // TODO(jmesserly): avoid the round tripping through quoted form.
 JS.LiteralString _propertyName(String name) => js.string(name, "'");
 
 // TODO(jacobr): we would like to do something like the following
@@ skipping 14 matching lines @@
 }
 
 bool isLibraryPrefix(Expression node) =>
     node is SimpleIdentifier && node.staticElement is PrefixElement;
 
 LibraryElement _getLibrary(AnalysisContext c, String uri) =>
     c.computeLibraryElement(c.sourceFactory.forUri(uri));
 
 bool _isDartRuntime(LibraryElement l) =>
     l.isInSdk && l.source.uri.toString() == 'dart:_runtime';