Fork me on GitHub
#cljsjs
<
2018-02-28
>
jannis10:02:41

Hi folks! I’ve been working on packaging some JS libraries (apollo-client, react-apollo etc.) for cljsjs. I’ve only been successful with UMD bundles. CommonJS bundles typically complain about exports not being defined (they all seem to start with Object.defineProperty(exports, '__esModule', ...). Is this expected? Are there some examples based on CommonJS bundles that I could explore?

jmckitrick13:02:42

I’m having exactly the same issue, @jannis

jannis14:02:05

@jmckitrick I’m pausing my efforts on this right now. I think I’ve patched the rollup and build configs of ~6-8 packages now to get to react-apollo and there are still a few missing. 😕

jmckitrick14:02:26

Ugh, that’s frustrating.

jannis14:02:55

Just a little. 😉

jmckitrick14:02:42

Are you committed to the cljsjs method?

jannis14:02:03

I’m confident all changes involving apollo are really upstream mistakes and will be accepted as PRs. But the official graphql library needs to be built differently and I’m not sure I can convince them to add another built command just for us. 😉

jannis14:02:15

@jmckitrick I’d rather solve it via :npm-deps but there are still problems with indexing the npm packages I’m trying to import.

jmckitrick14:02:04

Can you elaborate, @jannis? I’m new to :npm-deps so anything I can learn is good.

jmckitrick14:02:20

Specifically, indexing.

jannis14:02:32

Ha, if only I knew anything about it! 🙂

jannis14:02:49

You know what :npm-deps is?

jmckitrick14:02:17

Yes, I’m experimenting with it now, when I couldn’t get a cljsjs package to work 😉

jmckitrick14:02:58

I followed the directions, and both online extern extraction tools crapped out, saying the namespace I wanted was not found.

jmckitrick14:02:16

I’m going to start a blog and explain this once I figure it out lol

jannis14:02:54

Hehe, ok. So adding :npm-deps aims to allow importing any NPM packages so that you can (require [react :refer [createElement]]) them from a CLJS namespace. So far so good.

jannis14:02:20

That works fine with some/many packages. I’ll give you an example where it doesn’t currently work: graphql.

jannis14:02:01

The package.json of graphql has a "module": "index.mjs" entry, which CLJS currently doesn’t support (this is a theory, but given that it works once you rename it to index.js, I may be guessing right). As a result, goog.require('graphql') will not be able to resolve the module when loading the CLJS app in the browser.

jannis14:02:22

Because graphql isn’t indexed and added via goog.addDependency.

jmckitrick14:02:04

Ah, ok. I’ve so far not used goog.require

jannis14:02:11

It’s what CLJS uses under the hood to link the JS modules built for all the CLJS namespaces. And for external JS libraries.

jannis14:02:16

Shouldn’t really matter much, since it would work fine if it all required dependencies are added via cljs_deps.js.

jannis14:02:59

@jmckitrick Not until now. But yeah, if you can bundle all your dependencies together nicely that’s one way you could do it. Make sure to define externs though so optimized builds don’t break.

jmckitrick14:02:04

Hmm. Well, I wasn’t able to get the 2 components I needed to import in the ‘usual’ ways. Maybe I’m doing them wrong. But I saw your comment on the error with CommonJS modules, and that’s what I saw as well.