This seems fishy https://github.com/cljsjs/packages/blob/3ebea931981f7715ff598fd124e4fa93a69e8550/react-grid-layout/build.boot#L30
is there a reason the name react-input-autosize is being used here?
So when a package, like react-grid-layout only has the minified version available from github, do we only put it in the development folder? Or only the production folder?
@currentoor: Yeah, that's a wrong folder but it shouldn't cause any problems.
@currentoor: Some packages with only non-minified file but it in common
folder. development
is also okay.
@juhoteperi: this package has only minified files, development is still ok?
It will still work in advanced compilation?
@currentoor: Yes. Minified file is not required.
The path doesn't really matter. It is only a convention.
deps-cljs
uses file extension to select files for deps.cljs
@juhoteperi: Ah I see, thanks.
I was able to successfully bump the version of react-grid-layout to the latest (0.10.8). I’ll verify the new externs are correct in about a week. Should have a PR after that.
@juhoteperi: Im refactoring the webcomponents PR that I have, just wondering if I should have two packages for the lite and full versions?
@flyboarder: What difference there is with lite and full versions? How user selects which to use?
@juhoteperi: it’s based on which polyfills they want
Would be easiest if it was just webcomponents + webcomponents.shadow-dom :S
But damn JS people are trying to make things difficult for us
i know right 😕 maybe i should do each polyfill separately?
Looks like gulp file has separate build task for shadow-dom polyfill
and the difference between lite and full should be only the shadow-dom polyfill
At least that's what they say on readme, but I'm not sure by looking at their build scripts
https://github.com/webcomponents/webcomponentsjs/blob/master/gulpfile.js#L125-L130
looks like they got one for each
Yeah. I was checking difference between build.json and build-lite.json but I'm not sure how they work.
If possible, lite + shadow-dom would be best for packaging purposes. Could be exposed as two namespaces. You would need to call gulp from Boot but there should be plenty of example for that now.
But if there are problems with that, I'm okay with anything that works :simple_smile:
ok, ill give it a go with the build tasks
Oh, no need for calling gulp then,
yeah, im just wondering if it’s worth doing all the smaller packages as well?
shadow DOM on it’s own would probably be nice for people, but then might as well do them all?
Yeah. Also depends on what full package includes. Looks like it's 20KB more than just ShadowDOM.js and lite.js
i think it’s the mutation observer, shadow dom also has weakmaps
@juhoteperi: is there a way I can have cljsjs depend on another projects externs?
@flyboarder: No
ok, hey I was wondering what your thoughts are on a self updating cljsjs, I was thinking about ways that CI could run and update packages when upstream tags are pushed
Would be cool but I'm not sure if it's worth the effort and problems
fair enough, my thought was that most package updates are simple version and hash changes
I guess that's true
im not sure how the cljsjs site actually works tho so im just throwing ideas around
Site is just updated once an hour by checking versions from clojars. Packages repo is the one that matters.
ah i see, so the site doesnt rely on the packages repo directly, cool!