Fork me on GitHub
#cljsjs
<
2016-03-04
>
currentoor04:03:37

is there a reason the name react-input-autosize is being used here?

currentoor05:03:54

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?

juhoteperi05:03:19

@currentoor: Yeah, that's a wrong folder but it shouldn't cause any problems.

juhoteperi05:03:33

@currentoor: Some packages with only non-minified file but it in common folder. development is also okay.

currentoor05:03:27

@juhoteperi: this package has only minified files, development is still ok?

currentoor05:03:41

It will still work in advanced compilation?

juhoteperi06:03:34

@currentoor: Yes. Minified file is not required.

juhoteperi06:03:28

The path doesn't really matter. It is only a convention.

juhoteperi06:03:11

deps-cljs uses file extension to select files for deps.cljs

currentoor06:03:00

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.

flyboarder18:03:12

@juhoteperi: Im refactoring the webcomponents PR that I have, just wondering if I should have two packages for the lite and full versions?

juhoteperi18:03:07

@flyboarder: What difference there is with lite and full versions? How user selects which to use?

flyboarder18:03:40

@juhoteperi: it’s based on which polyfills they want

juhoteperi18:03:49

Would be easiest if it was just webcomponents + webcomponents.shadow-dom :S

juhoteperi18:03:04

But damn JS people are trying to make things difficult for us

flyboarder18:03:21

i know right 😕 maybe i should do each polyfill separately?

juhoteperi18:03:59

Looks like gulp file has separate build task for shadow-dom polyfill

juhoteperi18:03:11

and the difference between lite and full should be only the shadow-dom polyfill

juhoteperi18:03:39

At least that's what they say on readme, but I'm not sure by looking at their build scripts

flyboarder18:03:19

looks like they got one for each

juhoteperi18:03:45

Yeah. I was checking difference between build.json and build-lite.json but I'm not sure how they work.

juhoteperi18:03:07

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.

juhoteperi18:03:02

But if there are problems with that, I'm okay with anything that works simple_smile

flyboarder18:03:21

ok, ill give it a go with the build tasks

juhoteperi19:03:09

Oh, no need for calling gulp then,

flyboarder19:03:40

yeah, im just wondering if it’s worth doing all the smaller packages as well?

flyboarder19:03:13

shadow DOM on it’s own would probably be nice for people, but then might as well do them all?

juhoteperi19:03:49

Yeah. Also depends on what full package includes. Looks like it's 20KB more than just ShadowDOM.js and lite.js

flyboarder19:03:02

i think it’s the mutation observer, shadow dom also has weakmaps

flyboarder19:03:11

@juhoteperi: is there a way I can have cljsjs depend on another projects externs?

flyboarder19:03:02

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

juhoteperi20:03:53

Would be cool but I'm not sure if it's worth the effort and problems

flyboarder20:03:55

fair enough, my thought was that most package updates are simple version and hash changes

juhoteperi20:03:19

I guess that's true

flyboarder20:03:06

im not sure how the cljsjs site actually works tho so im just throwing ideas around

juhoteperi20:03:49

Site is just updated once an hour by checking versions from clojars. Packages repo is the one that matters.

flyboarder20:03:48

ah i see, so the site doesnt rely on the packages repo directly, cool!