Fork me on GitHub
#cljs-dev
<
2019-07-05
>
henryw37413:07:06

Hi @dnolen, I'm seeking your opinion please: When running cljs on node, and doing a require of a foreign lib, the foreign lib script is run even if that foreign lib ns has been required before. IOW foreign lib requires appear to work differently to regular ns requires. does this sound like a bug to you? There's more context about the particular reason this is causing me a problem here: https://github.com/clojure/clojurescript-site/issues/320

dnolen14:07:39

@henryw374 sidenote, you should file issues in JIRA not the GitHub issues for the website

dnolen15:07:21

@henryw374 but reading over that - there is no bug

dnolen15:07:15

seems like an issue w/ how you're trying to use random foreign-libraries, nothing specific to the foreign library feature in general

dnolen15:07:54

stepping back - I don't know why you need to bother

dnolen15:07:44

under Node.js you can use NPM libraries in a straightforward manner

dnolen15:07:23

@mfikes which reminds me - we should probably clarify the alpha bit about :npm-deps

mfikes17:07:56

Oh—I see you had subsequent comments on this…

dnolen15:07:33

it may give the impression that the Node.js support is a problem

dnolen15:07:38

it's not - that work is effectively done

henryw37415:07:30

@dnolen so are you saying foreign-libs are not intended to work on node? re: why I need to bother. I am the author of a cljs lib that depends on a foreign-lib. in it's docs it says 'if you're using shadow, do xyz'. so update that to include node? And ideally detect if the foreign-lib is being used on node and throw Currently, it kind of works as-is on node rather than completely or not at all.

dnolen15:07:09

I didn't say that, I said what you're trying to do - there no magic way for that to work

dnolen15:07:19

using random libraries that were packaged for the browser

dnolen15:07:13

libraries that must be consumed differently for different tools is not a good idea IMO

henryw37415:07:04

is there any way around that though if you want to depend on an npm-lib? npm-deps?

dnolen15:07:31

what you really want to do is on the near todo-list btw

dnolen15:07:17

@henryw374 the real answer is to have better integration w/ tools that solve this problem for JS already

dnolen15:07:42

but at the moment you don't have a ton of general options

dnolen15:07:08

React can in fact probably be made to work - but I would consider it too expert of an option for most poeple

dnolen15:07:10

what Thomas Heller was trying to say in the issue was the CLJSJS in general assumes browser - because that what most users are doing

dnolen15:07:17

that means they package a browser artifact

dnolen15:07:30

often that will create problems when loading that thing in Node

dnolen15:07:36

but that's not an issue w/ foreign libs - that's just how people use CLJSJS

henryw37415:07:16

fair enough. in my case, it would work on node if the foreign-lib require executed the script once at most, but I accept that's not a generally a problem. I'll have a read to understand the proposal. For now my lib will continue to need workarounds

dnolen15:07:05

the short summary

dnolen15:07:10

eliminate this problem entirely

dnolen15:07:26

everything is already in NPM, if you're using Node.js there's nothing to do

dnolen15:07:52

if you targeting the browser then support webpack build step and hide all the boring details

dnolen15:07:09

important thing - nobody is spending time packaging anything and potentially in the wrong way

dnolen15:07:32

finally, allow users to do exactly what you've described

dnolen15:07:44

your lib wants a transitive dep on something in NPM

henryw37415:07:42

ok cool. I need to read up more, but it sounds like the bottom line is that users of my lib will really need to have npm installed as a pre-requisite. Which seems reasonable, but inevitably that will put some people off I guess. It'd be interesting to know what proportion of cljs users that'd be

dnolen15:07:39

A lot of people will have Node installed - it’s really no longer rare

dnolen16:07:51

let me know if there are some tickets that need attending to

dnolen16:07:24

planning on working a bit more on the Closure library parsing stuff as well as dipping my toes into the transitive npm deps work