Fork me on GitHub
Slack Archive

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

2023-05-09

Channels

#shadow-cljs
<
2023-05-09
>
Blake Bergstrom12:05:31

Hello everyone. I am making a libary for cljs files I have created and wrap it in a npm package and my research is that shadow-cljs.edn can do that for me. But when I do the :exports I can't seem to get it right. Also I am new to the config of libs in shadow.

grav13:05:30

Did you check the guide? https://shadow-cljs.github.io/docs/UsersGuide.html#target-node-library Any specific part you're stuck in?

Blake Bergstrom14:05:25

Well I wanted to know also before I answer your question. What is better a npm module for a lib or a node-libary. I made custom cljs files and need to convert the project of just cljs files to a library then package it as an npm and I was led that shadow-cljs only does that

thheller15:05:02

is your intent for people to use it from cljs or js?

thheller15:05:55

"libary for cljs" suggests that cljs people will use it, in which case shadow-cljs is not used at all and you published uncompiled code via clojars, not npm

Blake Bergstrom15:05:18

Cljs. I am new to this and the internet said shadow-cljs will build it into a lib then I use npm to package it. Then in our main project I would install it then call the library in the files that were calling the specific file to use the fn. But I could be completely wrong and use clojars instead. Boss told me to look at different approaches. So if this wrong I am really sorry. And I didn't mean to waste your time.

thheller15:05:59

npm is not involved, and neither is any cljs compilation

Blake Bergstrom15:05:46

this is a proprietary lib and we don't want to put it on a centralized repo. Is there another answer?

thheller15:05:45

does it have a git repo? or how do you manage the sources? doesn't need to be github, any git will work

Blake Bergstrom15:05:13

Not currently I ripped out all of the cljs files that are needed for this lib into a simple deps.edn project. Then I wad trying to compile it. Then realized I was doing something wrong. Should I make a repo and commit the all my cljs files to it?

thheller15:05:53

well, you intend to make a library

thheller15:05:09

you need some way for others to get it. seems like git would be the easiest?

Blake Bergstrom15:05:11

Sure. I was told Git sha doesn't like cljs but i will try it. Thank you!

thheller15:05:58

not sure what you mean by that, but deps.edn with git seems like your best option

Blake Bergstrom15:05:10

Perfect. Thank you

Andrew Lai22:05:56

Hi all! I’m looking for some help with what I think is an npm-module compilation issue. Currently, I’m trying to incorporate JSX files into a Shadow CLJS build. My goal is to be able to adapt some react components written in JSX into a Clojurescript project. I also want to build Storybook stories using those components and have Shadow emit :npm-modules that are compatible Storybook stories. My current process is that I transpile JSX files into JS with Babel, then I compile them the JS together with CLJS using with shadow. I emit :npm-modules so I can load the files into storybook (because Storybook requires each story to be a module with a default export). When I compile using the :browser target everything builds and works just fine. But when I compile using :npm-module I’ve found that the compiled .js module output seems subtly broken. In my build, Shadow emits a file module$kaleidoscope$ui$components$js$Example.js - this emitted JS file is Shadow’s representation of the raw JS file that I want to incorporate into the build. This JS file relies on React, and that’s the problem: the emitted JS module currently cannot find react. The snippet below highlights the problem: On the last line of the emitted JS, there is a (require("shadow.js.shim.module$react")) which is passed to a function to create the _react object that the module relies on. If everything is working properly, the _react object will be used to create the component I want to use. However, the require statement doesn’t actually return any data structure - so _react is null (see snippet below). 

shadow$provide.module$kaleidoscope$ui$components$js$Example = function(global, require, module, exports) {
    Object.defineProperty(exports, "__esModule", {
        value: !0
    });
    exports.myComponent = function() {
        return _react.default.createElement("h1", null, "JSX! AND LESS")
    };
    var _react = function(obj) {
        return obj && obj.__esModule ? obj : {
            default: obj
        }
    // This requirement statement doesn't actually return an object
    // If we swap it out for the actual shim, it works just fine `shadow.js.shim.module$react`
    }(require("shadow.js.shim.module$react"))
}
However, if I directly replace the require statement with the shadow.js.shim.module$react (I believe a global that is generated from the shadow.js.shim.module$react.js file), everything seems to work just fine. Assuming the analysis makes sense - am I doing something wrong in my compilation? Or is this a subtle bug?

Andrew Lai22:05:21

There’s another layer involved too - Storybook has a built-in webpack bundling process and it does hot-code reloading. Since I only see the symptoms in Storybook, it’s possible Webpack is also interfering. I don’t know how to dive deeper than the analysis above and could definitely use some guidance

thheller10:05:04

which shadow-cljs version do you use? I think I fixed this particular issue some weeks ago?

Andrew Lai12:05:30

I’m on 2.23.3

Andrew Lai12:05:23

I did manage to get a workaround by running npm install ./some-local-directory-with-js. But I’d love to find a way to get it working without installing as a node_module because installing as a node_module seems to break shadow’s hot-reloading.

thheller13:05:35

if you make a repro I can take a look, otherwise I'm just guessing in the dark which is not very productive

Andrew Lai13:05:28

I’ll try to make a minimal repro, but will probably take a day or so to do it.

Andrew Lai17:05:23

Here’s a minimal reproduction example/repo https://github.com/ALai57/shadow-npm-module-issue. The README has the documentation to be able to reproduce the problem I was running into.

Andrew Lai17:05:48

I tried cloning it to my machine and following the README and it seemed to faithfully reproduce the problem - let me know if you run into any issues reproducing the problem

Andrew Lai13:05:38

Just wanted to bump this conversation - @thheller, would you be able to help me look at the reproduction of the compilation issue or guide me on how to self-serve to look into the root cause?

thheller13:05:49

didn't have time to check so far, but I have a couple mins now. let me check how hard it is to fix

thanks3 1
Andrew Lai13:05:03

Just wanted to bump this conversation - any luck investigating this compilation behavior? Were you able to reproduce the issue on your end?

Andrew Lai13:05:38
replied to a thread:Hi all! I’m looking for some help with what I think is an `npm-module` compilation issue. Currently, I’m trying to incorporate JSX files into a Shadow CLJS build. My goal is to be able to adapt some react components written in JSX into a Clojurescript project. I also want to build Storybook stories using those components and have Shadow emit `:npm-modules` that are compatible Storybook stories. My current process is that I transpile JSX files into JS with Babel, then I compile them the JS together with CLJS using with shadow. I emit `:npm-module`s so I can load the files into storybook (because Storybook requires each story to be a module with a default export). When I compile using the `:browser` target everything builds and works just fine. But when I compile using `:npm-module` I’ve found that the compiled `.js` module output seems subtly broken. In my build, Shadow emits a file `module$kaleidoscope$ui$components$js$Example.js` - this emitted JS file is Shadow’s representation of the raw JS file that I want to incorporate into the build. This JS file relies on React, and that’s the problem: the emitted JS module currently cannot find `react`. The snippet below highlights the problem: On the last line of the emitted JS, there is a `(require("shadow.js.shim.module$react"))` which is passed to a function to create the `_react` object that the module relies on. If everything is working properly, the `_react` object will be used to create the component I want to use. However, the `require` statement doesn’t actually return any data structure - so `_react` is null (see snippet below). shadow$provide.module$kaleidoscope$ui$components$js$Example = function(global, require, module, exports) { Object.defineProperty(exports, "__esModule", { value: !0 }); exports.myComponent = function() { return _react.default.createElement("h1", null, "JSX! AND LESS") }; var _react = function(obj) { return obj &amp;&amp; obj.__esModule ? obj : { default: obj } // This requirement statement doesn't actually return an object // If we swap it out for the actual shim, it works just fine `shadow.js.shim.module$react` }(require("shadow.js.shim.module$react")) } However, if I directly replace the `require` statement with the `shadow.js.shim.module$react` (I believe a global that is generated from the `shadow.js.shim.module$react.js` file), everything seems to work just fine. Assuming the analysis makes sense - am I doing something wrong in my compilation? Or is this a subtle bug?

Just wanted to bump this conversation - @thheller, would you be able to help me look at the reproduction of the compilation issue or guide me on how to self-serve to look into the root cause?

Andrew Lai13:05:03
replied to a thread:Hi all! I’m looking for some help with what I think is an `npm-module` compilation issue. Currently, I’m trying to incorporate JSX files into a Shadow CLJS build. My goal is to be able to adapt some react components written in JSX into a Clojurescript project. I also want to build Storybook stories using those components and have Shadow emit `:npm-modules` that are compatible Storybook stories. My current process is that I transpile JSX files into JS with Babel, then I compile them the JS together with CLJS using with shadow. I emit `:npm-module`s so I can load the files into storybook (because Storybook requires each story to be a module with a default export). When I compile using the `:browser` target everything builds and works just fine. But when I compile using `:npm-module` I’ve found that the compiled `.js` module output seems subtly broken. In my build, Shadow emits a file `module$kaleidoscope$ui$components$js$Example.js` - this emitted JS file is Shadow’s representation of the raw JS file that I want to incorporate into the build. This JS file relies on React, and that’s the problem: the emitted JS module currently cannot find `react`. The snippet below highlights the problem: On the last line of the emitted JS, there is a `(require("shadow.js.shim.module$react"))` which is passed to a function to create the `_react` object that the module relies on. If everything is working properly, the `_react` object will be used to create the component I want to use. However, the `require` statement doesn’t actually return any data structure - so `_react` is null (see snippet below). shadow$provide.module$kaleidoscope$ui$components$js$Example = function(global, require, module, exports) { Object.defineProperty(exports, "__esModule", { value: !0 }); exports.myComponent = function() { return _react.default.createElement("h1", null, "JSX! AND LESS") }; var _react = function(obj) { return obj &amp;&amp; obj.__esModule ? obj : { default: obj } // This requirement statement doesn't actually return an object // If we swap it out for the actual shim, it works just fine `shadow.js.shim.module$react` }(require("shadow.js.shim.module$react")) } However, if I directly replace the `require` statement with the `shadow.js.shim.module$react` (I believe a global that is generated from the `shadow.js.shim.module$react.js` file), everything seems to work just fine. Assuming the analysis makes sense - am I doing something wrong in my compilation? Or is this a subtle bug?

Just wanted to bump this conversation - any luck investigating this compilation behavior? Were you able to reproduce the issue on your end?