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.

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

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

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?

its probably https://caniuse.com/#feat=array-includes

so yeah that needs a polyfill for IE

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?

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

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

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

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) {

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

thanks!

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

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

guess I need to call something to trigger it

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

it's called on initial render in my app

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

ah okay 👍

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

will fix later

awesome

see https://github.com/thheller/shadow-cljs/issues/337

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

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.

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

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

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).

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

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.

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

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.

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

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.

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.

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

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

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.

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

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

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

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.

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

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

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

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

gotta end this CommonJS mess at some point anyways 😉

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

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

so commonjs is the only common denominator still.

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

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

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

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

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

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

and let tools do the rewriting

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

ah I see

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

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

yeah it is available more frequently

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

its much safer to only use CommonJS only or ES6 only

the interop story sucks

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

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