Clojurians
#cljs-dev
<
2017-08-30
>

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

thheller08:08:08

@juhoteperi I’m a bit confused by https://github.com/cljsjs/packages/blob/master/react/resources/react-deps.cljs. why :provides and :global-exports? wouldn’t just :global-exports be enough? or can it only global export aliases it provides?

thheller08:08:20

and why repeat the entry instead of adding cljsjs.react to the first :provides?

juhoteperi08:08:39

@thheller :global-exports doesn't replace :provides, both are required

juhoteperi08:08:16

I'm not sure if foreign-lib providing both react and cljsjs.react would work, that would simplify things

juhoteperi10:08:17

@thheller Yes, providing both names from same foreign-lib seems to work: https://github.com/cljsjs/packages/compare/unified-foreign-lib?expand=1

juhoteperi10:08:04

@dnolen Re: https://dev.clojure.org/jira/browse/CLJS-2331, have you though how this would work when using Node Modules? If there is foreign-lib with global-exports with name in global-exports, the code would be rewritten to use processed module instead of foreign-lib?

thheller10:08:16

ok cool, my handling of foreign-libs in shadow-cljs is a bit different and it got confused by the same file being used twice

juhoteperi10:08:38

I think ClojureScript uses :file to group foreign-libs

thheller10:08:41

I’ll just add a special case that merges the :provides in that case

thheller10:08:12

yeah so do I but the :file is duplicate in that case

thheller10:08:21

so one entry got lost

juhoteperi10:08:08

Hm, ClojureScript handles it in a way that no foreign-lib entry is lost, but only one file is added to output

juhoteperi10:08:07

lib-spec-merge even has some specific logic for :provides

thheller10:08:51

no idea whats going on in that code :slightly_smiling_face:

dnolen10:08:20

@juhoteperi don't know what you mean 2331

thheller10:08:30

doesn’t matter though, I’ll just go by the :provides and de-dupe based on :file. shouldn’t be an issue if you merge the unified deps.cljs

dnolen10:08:18

@juhoteperi you should be able to collapse that deps.cljs, multiple provides supposed to work

dnolen10:08:59

But that does work anyway, you can always override foreign lib spec via file or provides

juhoteperi11:08:07

Yes, I did merge foreign-lib entries in cljsjs using global-exports, and it does work

juhoteperi11:08:33

Not sure why I didn't try this earlier, this will be easier to understand than multiple entries

juhoteperi19:08:30

Chad just completed the UMD wrapper work I wrote the tests for (and made few small improvements)

juhoteperi19:08:20

Leaflet wrapper is now correctly removed, but now a few new problems with function hoisting (in leaflet) and ES6 modules (in react-leaflet) can be seen

anmonteiro19:08:25

hope that makes it to the next release

anmonteiro19:08:38

as well as my other one for the browser field

juhoteperi19:08:42

module$home$juho$Source$x$y$node_modules$prop_types$index["default"].oneOfType this is from a ES6 file, I think the ["default"] shouldn't be here

juhoteperi19:08:16

prop-types is just CJS

juhoteperi19:08:16

and these imports in lodash-es are not converted: import root from './_root.js';

juhoteperi19:08:12

which is strange because imports in react-leaflet are converted, hmm

juhoteperi19:08:30

Hmm, cljs does have some changes related to es6 exports at least?

juhoteperi19:08:37

Maybe I should try with cljs master also

anmonteiro19:08:15

looks like a Closure thing, not CLJS

juhoteperi20:08:07

Haha, some lodash-es modules have checks that test module and exports, Closure detects those as UMD wrappers so the ES6 imports are not converted