Clojurians
#cljs-dev
<
2016-01-12
>

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

juhoteperi21:01:05

Hm, would be easy to add goog.module support to cljs.js-deps/parse-js-ns but I'm not sure if there is any promises that goog.require calls are in the start of file when using goog.module. Currently only lines before first function declaration are read.

juhoteperi21:01:35

Also, I would the following in goog.module proposal and I'm not sure if this means that goog.module declared namespaces are not usable from a legacy files: > As envisioned, it will still be possible to goog.require a goog.module file from a legacy file, but the module symbol would not be accessible. This kind of usage should be flagged by the compiler as a possible misuse.

juhoteperi21:01:37

This might also be relevant: > Allow goog.module namespace to be populated in global scope behind a goog.define. This would allow unilateral conversion of files regardless of its dependencies, otherwise only leafs projects could take advantage of goog.module (similar to @struct and AJD). *There is no plan to implement this.*

juhoteperi21:01:27

That page contains answer on how to use goog.modules from legacy/traditional files

dnolen21:01:07

@juhoteperi: parse-js-ns is should probably be replaced with whatever Closure has for doing this

dnolen21:01:29

I’m pretty sure it has built-in functionality that’s slightly more reliable than our regex approach

dnolen21:01:17

@juhoteperi: yeah somebody needs to do a lot more research about the scope and intent of goog.module

dnolen21:01:39

GCL hasn’t switched to it so it may be something driven by some users not something that Google uses more broadly

juhoteperi21:01:10

I'll create an issue and continue research later

dnolen22:01:06

heh, oh well