Fork me on GitHub
#shadow-cljs
<
2018-07-04
>
thheller09:07:29

I just pushed 2.4.15 that now automatically deals with the global use of Buffer which previously required an ugly hack. Anyone using such a Buffer hack please try it without in 2.4.15.

thheller09:07:21

I adopted that behaviour since too many packages blindly use the global Buffer and webpack and others just rewrite it

thheller09:07:12

web3 notoriously uses the Buffer object almost everywhere which should just work now without any hacks

Pontus14:07:17

Hello, I'm getting this error in the main bundle of my app in Internet Explorer 11: Object doesn't support property or method 'includes', do I have to manually somehow include a polyfill to resolve this?

thheller14:07:30

so yeah that needs a polyfill for IE

Pontus14:07:48

okay, I've done that for js projects using babel in the past but I'm a bit confused how to set it up with shadow-cljs, is there an example anywhere on how to do it?

thheller14:07:49

@pontus.colliander which part of the code uses .includes? closure usually is supposed to automatically inject polyfills like that

thheller14:07:13

or are you using a dev build? it might work with shadow-cljs release?

Pontus14:07:03

hm no I'm using shadow-cljs release app when compiling

Pontus14:07:37

looks to me like it's atlaskit npm module that I installed, it's inside a function named shadow$provide.module$node_modules$$atlaskit$analytics_next$dist$cjs$withAnalyticsEvents = function(a, k, b, f, c) {

thheller14:07:14

ok, I'll check why it doesn't add the polyfill

thheller14:07:04

do you know where the error occurs? after calling which function?

thheller14:07:18

just adding ["@atlaskit/analytics-next" :as as] does not cause the error

thheller14:07:24

guess I need to call something to trigger it

Pontus14:07:43

It's in a method called this.mapCreateEventsToProps = function(c, d)

Pontus14:07:55

it's called on initial render in my app

thheller14:07:15

I reproduced with (.includes #js [1 2 3] 3)

Pontus14:07:31

ah okay 👍

thheller15:07:23

ok found it. there is some weird interaction between the polyfills stuff and the node_modules file polyfills get lost

👍 4
thheller15:07:25

will fix later

hlolli15:07:04

I've been lately on and off cljs, was there any clean way to require .-default avaialable?

hlolli15:07:11

just from 2 months, I reopened a project and so many components were crashing, due to newer versions of libs are useing the default export option. But to be expected, easy fix.

thheller15:07:23

@hlolli (:require ["thing" :default foo]). not official yet but works in shadow-cljs. https://dev.clojure.org/jira/browse/CLJS-2376

🎉 4
urbanslug21:07:46

are you guys using clj-fmt? Which linting/style tool are you using seems clj-fmt requires leiningen

hlolli21:07:36

I'm testing out webpack + shadow.cljs, I fell in love with the file loader in a different project. Was there ever an idea proposed to make a shadow-cljs loader, simply trigger shadow-cljs compile on changes/matched regex(for prod).

thheller21:07:40

file loader is pointless. just compile with :npm-module and include the file directly via import or require

hlolli21:07:55

hmm, does that work for images as well? One thing I liked was for example in scss, @import "~../../node_modules/slick-carousel/slick/slick.css"; this could just pack it into my css output.

thheller21:07:51

I'm confused. you want to do that in CLJS or via webpack?

hlolli21:07:01

If possible in CLJS, then I don't see reason to use webpack, but with webpack you can import an image and css with image-loader and css-loaders.

thheller21:07:38

yeah I'm never ever going to implement that via ns require. I do however have plans to add something similar via some macros

hlolli21:07:50

ok I'm just experimenting. But webpack should understand js/require and that would trigger the loader, returning either image url or base64 of the image.

hlolli21:07:33

I used to hate webpack 🙂, but the idea of requireing styles from node_modules was an eye opener. And its way more stable than when I was struggling with it few years back.

thheller21:07:01

yeah the idea is nice. just hacking it into js/require is horrible IMHO

thheller21:07:08

but I guess they have to since they don't have macros

hlolli21:07:46

yes I guess they do that. But I hacked js/require once when I was bundling a lumo app into a binary. Can be horrible and powerful.

thheller21:07:35

getting a bit frustrated with JS lately due to the many hacks people have adopted

thheller21:07:54

makes it an absolute nightmare to write a reasonable tool to bundle it

thheller21:07:39

I shouldn't have written the build reports feature, too much insights into the horrors of some JS packages 😛

hlolli21:07:07

yes, I think that awakening is everywhere. Of the js tools, very sad to see how gulp is sinking in standard. It was a potential for clean build and deploy tool. But all hot-reload tutorials for gulp, is basically useing webpack in gulp, with webpack-stream, and from that point, you're in js tool hell.

hlolli21:07:14

and no wepack boilerplate in the code, just purely combine compilations like they were indended, in streams

thheller21:07:46

just today I added support for the dreaded global Buffer support that works in node and the browser thanks to webpack only

thheller21:07:21

or I guess browserify too. If they had just decided to not support it people would be using require("buffer") properly instead today

thheller21:07:12

really wish there was a package manager for JS that only accepted valid linted ES6 code

thheller21:07:44

gotta end this CommonJS mess at some point anyways 😉

hlolli22:07:10

yes, start by haveing nodejs understanding it without babel, wasn't that the plan anyway, I take babel for granted.

thheller22:07:03

no babel please. that is reponsible for half of the misery

hlolli22:07:24

so commonjs is the only common denominator still.

thheller22:07:15

wish it was ES6. would make life to much easier.

hlolli22:07:43

then you're refering to node modules that are released as es6? Isn't that very rare

Space Guy22:07:54

It'd be a good start, but you'd still need babel for 'server-side jsx' or whatever

hlolli22:07:09

just looking over my node_modules, always common.js I think, with source maps maybe to es6

thheller22:07:17

don't really care about node. thats gonna need to adopt ES6 at some point too.

thheller22:07:41

point is to only publish standards compliant ES6+ code to npm

thheller22:07:47

and let tools do the rewriting

thheller22:07:02

NOT publish rewritten code and let tools figure out what was rewritten

thheller22:07:33

I think every JS builds with even a small number of JS deps ends up including three different Object.assign polyfills

hlolli22:07:51

isn't it possible now to publish both .es6 and .js, I've seen it many times with typescript based libs

thheller22:07:13

yeah it is available more frequently

thheller22:07:32

but one major source of pain is CommonJS <-> ES6 interop

thheller22:07:42

its much safer to only use CommonJS only or ES6 only

thheller22:07:46

the interop story sucks

thheller22:07:08

getting better since webpack adopted a stricter version as the default but still bad

hlolli22:07:40

yup, as consumer of libs I don't notice it, except useing require vs import, but you're creating tools, so I guess you have different view of this