Devtools: [WIP] Implement enhanced devtools extension language APIs

Source/devtools/front_end/common/ResourceType.js

Index: Source/devtools/front_end/common/ResourceType.js
diff --git a/Source/devtools/front_end/common/ResourceType.js b/Source/devtools/front_end/common/ResourceType.js
index 88ec23b8698646a6bf537be5dd7353925e637e67..7b002727d23b563e8ad89c46746241d7cfc7a6e6 100644
--- a/Source/devtools/front_end/common/ResourceType.js
+++ b/Source/devtools/front_end/common/ResourceType.js
@@ -136,7 +136,39 @@ WebInspector.resourceTypes = {
     Other: new WebInspector.ResourceType("other", "Other", "Other", "Other", "rgb(186,186,186)", false)
 }
 
-WebInspector.ResourceType.mimeTypesForExtensions = {
+/**
+ * @param {string} url
+ * @return {string}
+ */
+WebInspector.ResourceType.mimeFromUrl = function(url) {

[pfeldman, 2015/08/13 21:15:46]

mimeFromURL would be all caps
we place { on the next line everywhere

[wes, 2015/08/14 00:55:04]

Acknowledged.

+    var name = WebInspector.TextUtils.fileName(url);
+    if (WebInspector.ResourceType.mimeTypeNameMatches[name]) {
+        return WebInspector.ResourceType.mimeTypeNameMatches[name];
+    }
+    var ext = WebInspector.TextUtils.extension(url).toLowerCase();
+    return WebInspector.ResourceType.mimeTypeExtensionMatches[ext];
+}
+
+/**
+ * @param {string} match
+ * @param {string} mime
+ * @param {boolean=} matchName
+ */
+WebInspector.ResourceType.registerMimeRecognizer = function(match, mime, matchName) {

[pfeldman, 2015/08/13 21:15:46]

This signature and the method logic are very confusing.

[wes, 2015/08/14 00:55:04]

Does it need better argument names? Ie:

+/**
+ * @param {string} fileExtensionOrNamePattern
+ * @param {string} mime
+ * @param {boolean=} matchName
+ */

Or should it be broken out into two methods (one for by-extension, one for
by-name) across the entire stack?

[pfeldman, 2015/08/17 21:15:51]

Well, registerRecognizer suggests that it'll be a callback registered here.
Could fileExtensionOrNamePattern be unified into one fileNamePattern? It is not
clear what mime is doing and why it is important, etc. What do you intend to do
here?

+    var matches = WebInspector.ResourceType.mimeTypeExtensionMatches;
+    if (matchName) {
+        matches = WebInspector.ResourceType.mimeTypeNameMatches;
+    }
+
+    matches[match] = mime;
+}
+
+WebInspector.ResourceType.mimeTypeNameMatches = {
+    // CoffeeScript
+    "Cakefile": "text/x-coffeescript"
+}
+
+WebInspector.ResourceType.mimeTypeExtensionMatches = {
     // Web extensions
     "js": "text/javascript",
     "css": "text/css",
@@ -166,6 +198,7 @@ WebInspector.ResourceType.mimeTypesForExtensions = {
 
     // TypeScript
     "ts": "text/typescript",
+    "tsx": "text/typescript",
 
     // JSON
     "json": "application/json",
@@ -197,3 +230,19 @@ WebInspector.ResourceType.mimeTypesForExtensions = {
     // Video Text Tracks.
     "vtt": "text/vtt"
 }
+
+/**
+ * @return {string}
+ * @suppress {missingProperties}
+ */
+WebInspector.ResourceType.fromActivePanel = function() {
+    if (self.runtime.moduleIsLoaded("sources")) {
+        try {
+            return WebInspector.ResourceType.mimeFromUrl(WebInspector.SourcesPanel.instance().sourcesView().currentUISourceCode().contentURL());

[pfeldman, 2015/08/13 21:15:46]

You should never reach out to the module you don't depend on - this code won't
compile. You should runtime-based DI for that.

[wes, 2015/08/14 00:55:04]

I mean, it does compile (and run) thanks to the 
* @suppress {missingProperties}
annotation but it's more like a band-aid, since the 'correct' way to do it
is rather expensive for what amounts to a utility function. 

ANYWAYS! So, what would be the correct way to inject this information into a
scope accessible to
locations which call out to the language service manager? We want to reach into
the source module for information if its available, but without depending on
it...
I suppose I could define an interface for a delegate which provides this
function
and load it as an extension here?

[wes, 2015/08/14 01:25:50]

But if I did that then the module the extension was in would get loaded. 
Which isn't a thing we want. (Since we don't want any info from the module if it
doesn't exist) :(
Suggestions?

[pfeldman, 2015/08/17 21:15:51]

We have plenty of DI and context to handle this. You need a current
UISourceCode, right? That would be
WebInspector.context.flavor(WebInspector.UISourceCode). Make sure SourceViewer
maintains the right UISourceCode instance in the context though. Is probably
worth a separate change. You can even listen to the change to the flavor from
your module.

[wes, 2015/08/25 18:13:18]

But... the contexts in which we'd like to know this information (within the
languages module) we don't have access to the UISourceCode type at _all_ (since
it's a class from the lazily loaded sources module)... I suppose if languages is
changed to be lazy and depend on sources then it works? Hm... The issue with
that is that the extensions depends on languages, and extensions is eagerly
loaded... And the registration and management part of the languages module
really does need to be eagerly loaded with it, so it's there to handle extension
requests...

I could break it apart into two modules, languages and languages_lazy -
languages being the management portion that gets eagerly loaded, and
languages_lazy being the implementations? But even then there's still the issue
that sources would need to depend on languages_lazy and languages_lazy would
need to depend on sources... Unless languages_lazy's components in sources get
loaded as extensions, then it works.

So... break languages down into a lazy part and an eager part, make the lazy
part depend on sources, then inject it where required?

+        } catch (e) {
+            return "text/javascript";
+        }
+    } else {
+        return "text/javascript";
+    }
+}