Support for ES6 'goog:foo.bar.baz' imports

[jdb8]

The latest versions of google closure support es6 modules, as well as closure-specific module syntax in the form of import foo from 'goog:foo.bar.baz'. This allows for files (for example, the google closure js library itself) to continue to goog.provide('foo.bar.baz') while having their code imported into es6 modules.

Would it be simple to make this work with the loader, and correctly resolve both new- and old-style imports/requires? I've had a first attempt at modifying the loader, adding an additional regex in the form of ^import (.+) from ['"]goog:(.+)['"], but can't get things working yet: I intend to continue testing this out but thought I'd post here in the meantime in case there's any existing work on this or any roadblocks I'm overlooking.

Just to clarify, my intention would be only to transpile these special prefixed imports, and leave the pure es6 imports down to something like babel-loader since that feels more appropriate.

[eXaminator]

Hi @jdb8,

the main focus of this loader is to enable developers to keep using code files that make use of goog.provide and goog.require until they have can upgrade to a proper module system.

The syntax you describe is non-standard ES2015 and specific to the closure compiler. I do not aim to fully replace the closure loader. If you use the given syntax you are already inside a ES2015 file and thus could use any other import.

That being said: I would be willing to merge a PR if you also provide an example that shows the syntax being used and which updates the readme. Also please think about making this feature opt-in via the configuration.

I think your RegEx is a good start and you should handle it mostly like a goog.require with the same values, so I guess it shouldn't be too hard.

[jdb8]

Hey @eXaminator,

Thanks for responding so quickly. I agree that the purpose of the closure-loader should stay as you've described. However, for anyone who is aiming to transition to a codebase consisting purely of ES2015 imports/exports, and is also tied down to the closure library (which doesn't provide native ES2015 exports), using the pseudo-ES2015 syntax described above is somewhat of a necessity as an interim step as far as I can see.

My understanding of webpack's loader system is not complete, but I was under the impression that it's totally possible and supported to run two loaders on the same set of files - for example, in my tests I added babel-loader with the ES2015 plugin enabled, which seemed able to deal with the non-goog ES2015 imports appropriately while delegating to closure-loader for anything else. It's possible that this is not the case though: I'll need to try out some more examples and make sure nothing conflicts (I feel like babel may possibly choke on anything non-standard which resembles an ES2015 import, but perhaps it's written better than that :)

Anyway, I'm glad you're open to receiving PRs on this! I'll play around and see if anything's possible without moving away from the core focus of this loader. Worst-case scenario, I can look into forking this for my purposes or moving some additional logic to a plugin which I'm writing anyway. Thanks for providing this in the first place!

[eXaminator]

You are right about loaders and any loader that would parse this syntax would need to be run before babel.

Loaders simply receive a string of code and transform it in some way. The transformed code will then be passed to the next loader in line.

Thus I would expect the easiest way for this to work be to replace matching import statements (probably with a regex like the one you described) with actual commonjs requires (they are a bit simpler for this case than just rewriting the actual ES6 import), just like the closure-loader already does for goog.require statements.

So it might actually be enough to check for your RegExp (in addition to the goog.require RegExp) and do the same processing (you will have to change the variable name that this will be assigned to though).

I would help more, but I don't have a lot spare time right now and as I myself don't have any use for this right now I would rather use my time for other stuff ;-)

But I'll gladly help you in trying to answer your questions regarding this.

[jdb8]

Great. This sounds like the approach I started with, so I'm glad to know there shouldn't be any major blockers.

Thanks for your help, I'll let you know if there are any unforeseen blockers.