I’d like to detect if some JS code is compiled CLJS - can I do that to any degree of reliability? Is the imul fix still prepended to all compiled CLJS?

I posted a write-up / some questions on the gist. Hope it’s constructive!

@dnolen yes its important to be able to control how something resolves. In shadow-cljs this is done via :resolve config which matches what webpack does. https://shadow-cljs.github.io/docs/UsersGuide.html#js-resolve

@cfleming only for compiled builds

@lilactown thanks for the questions I left some answers

FWIW I created a simple example repo using code-splitting which I had difficulty with when trying to use webpack to do the splits https://github.com/thheller/code-splitting-challenge

If someone wants to work through webpack config a bit I'm sure there is an acceptable solution somewhere

@thheller thanks, very helpful

@thheller in that scenario you don't say outright here what was wrong

react-table & react-select get moved to main in Webpack?

huh wow I've definitely been out of the Webpack loop - I guess they have Rollup style tree shaking now?

https://webpack.js.org/guides/tree-shaking/

Also wasn't aware that Chrome now let's you see coverage - https://hackernoon.com/lessons-learned-code-splitting-with-webpack-and-react-f012a989113

yeah chrome tooling is fantastic

webpack got tree shaking a while ago yes but its fairly limited in the type of packages it supports

some libraries instead came up with their own way to do this ... eg. https://github.com/ant-design/babel-plugin-import

so its a total mess ....

but at least things are starting to get somewhat clearer now that multiple JS bundlers support this construct

I'm a bit concerned that everything is moving towards dynamic import() but the closure compiler folks started work on adding support for that

so I guess we'll see how that all works out

even libs?

yeah unfortunately

ouch

React is pushing using dynamic imports a lot with React.lazy. I would imagine once there’s prolific support for it that you might even see UI libraries leveraging it

yeah ... some lib on npm already started doing that for react. can't remember the name.

this is irrelevant to the discussion at hand, but I want to know how BuckleScript / PureScript / Elm et. al. handle mapping their lang’s namespaces to JS modules for tree shake-ability

don't they all just emit ES6?

I guess Elm has their own thing, but I know BuckleScript expects that you are bundling it yourself. they simply do a source -> source compile

yeah

afaik Elm is doing DCE before emitting JS

yeah, I remembered that Elm implements their own whole-app optimizer / bundler

so folks are doing lazy imports and assuming Webpack will do sensible chunks so you don't just end up with a lot of network requests?

that appears to be the direction they are going with yes

yuck

I just pushed a small change to master, goog.global is now explicitly mapped to Node.js global when compiling Node.js target. Useful when deploying hybrid Webpack / Node.js stuff

actually thats not that simple

goog/base.js already uses goog.global several times when loading

so if you bind it in cljs.core some of the goog defines it does end up on the wrong object

ie. goog.DEBUG

this is only if COMPILED is true

goog.DEBUG is a define

I can't think of scenario where this would matter in Node.js but if you want to enumerate something more specific - I'm all ears

re: I also had a thought about default w/o futzing around (too much) with the ns form

Clojure does a thing for inlined classes Foo$Bar, which I kind of adopted for foo$macros

but actually this seems like a good option for default, foo$default

no clue what you mean. can you provide an actual example?

hrm, I guess I was thinking about the problems we encountered w/ Closure processing, and import and the need to go through default property for the default export

is this not a concern with A) Node.js because native ES6 support and B) Webpack handles it

?

closure processing will rewrite all commonjs to one single .default property yes. but this is not relevant here.

JS packages will still have a default export, and in fact the strict mode webpack will also do the rewrite to .default for commonjs

ah k

import {foo, bar} from "./common.js" is not allowed

webpack still accept it I believe unless you are setting strict mode

@thheller hrm then revisiting what you were saying yesterday about reshaping I guess we don't need reshaping if we consistently support invoking the imported lib as a fn?

that's the only other annoying case

hrm well

actually I guess sometimes people export a ctor?

but I guess that could be covered by support invoke always and making sure we don't prevent using it as ctor for some reason

people do all kinds of weird stuff

JS for some reason doesn't support combining :as and :refer

so (:require [some-npm-lib :as x :refer (Foo Bar)]) can't be expressed in import

doesn't matter for us as a compile-to-js language but this seems to be leading people down strange roads

where the do import Something from "x"; and then actually having all the names exported on Something so Something.Foo

in actual ESM, not in weird rewritten commonjs

@thheller so you have import twice? for :as + :refer?

import {foo, bar} from "lib"; and import * as x from "lib"; yes

import * as x, {foo, bar} from "lib"; is invalid?

yep, not allowed

but * is bad for webpack tree shaking anyways so its use is discouraged anyways

https://medium.com/webpack/webpack-4-import-and-commonjs-d619d626b655

although the article is about dynamic import it applies just as much to static import

the annoying thing is __esModule which is still supported in webpack4 but I believe might be going away in 5

closure compiler folks do not support it at all and treat the files as commonjs