This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-08-30
Channels
- # aws (2)
- # beginners (139)
- # boot (9)
- # cider (1)
- # clara (2)
- # cljs-dev (35)
- # cljsrn (3)
- # clojure (112)
- # clojure-dusseldorf (9)
- # clojure-greece (6)
- # clojure-italy (13)
- # clojure-russia (160)
- # clojure-seattle-old (1)
- # clojure-uk (79)
- # clojurescript (85)
- # clojutre (1)
- # community-development (11)
- # core-async (32)
- # cryogen (2)
- # cursive (5)
- # data-science (16)
- # datomic (2)
- # events (1)
- # fulcro (29)
- # funcool (1)
- # graphql (4)
- # immutant (5)
- # instaparse (20)
- # jobs (2)
- # juxt (6)
- # leiningen (11)
- # luminus (21)
- # lumo (1)
- # off-topic (7)
- # onyx (20)
- # parinfer (33)
- # pedestal (4)
- # re-frame (41)
- # reagent (34)
- # ring-swagger (14)
- # rum (5)
- # spacemacs (9)
- # specter (11)
- # sql (14)
- # test-check (3)
- # yada (20)
@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?
@thheller :global-exports
doesn't replace :provides
, both are required
I'm not sure if foreign-lib providing both react and cljsjs.react would work, that would simplify things
@thheller Yes, providing both names from same foreign-lib seems to work: https://github.com/cljsjs/packages/compare/unified-foreign-lib?expand=1
@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?
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
I think ClojureScript uses :file
to group foreign-libs
Hm, ClojureScript handles it in a way that no foreign-lib entry is lost, but only one file is added to output
Hmm, or maybe it does merge the entries with same :file
: https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/js_deps.cljc#L149
lib-spec-merge
even has some specific logic for :provides
@juhoteperi don't know what you mean 2331
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
@juhoteperi you should be able to collapse that deps.cljs, multiple provides supposed to work
But that does work anyway, you can always override foreign lib spec via file or provides
Yes, I did merge foreign-lib entries in cljsjs using global-exports, and it does work
Not sure why I didn't try this earlier, this will be easier to understand than multiple entries
Chad just completed the UMD wrapper work I wrote the tests for (and made few small improvements)
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
exciting!
hope that makes it to the next release
as well as my other one for the browser field
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
prop-types is just CJS
and these imports in lodash-es are not converted: import root from './_root.js';
which is strange because imports in react-leaflet are converted, hmm
Hmm, cljs does have some changes related to es6 exports at least?
Maybe I should try with cljs master also
looks like a Closure thing, not CLJS
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