Fork me on GitHub
Slack Archive

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

2020-04-24

Channels

#shadow-cljs
<
2020-04-24
>
rberger08:04:37

Having a weird problem with the latest aws-amplify npm library (3.0.8). They seem to have done a major re-org of it and the latest version causes the following error when shadow-cljs trys to build a simple program that uses aws-amplify and aws-amplify-react: 

[:app] Build failure:
The required JS dependency "http2" is not available, it was required by "node_modules/@aws-sdk/node-http-handler/build/node-http2-handler.js".

rberger08:04:49

If I roll back to the pre 3.x.x version I don’t have that error.

thheller08:04:55

what build :target is this?

thheller08:04:58

why is that include a package that looks like it is meant for node?

thheller08:04:08

@aws-sdk/node-http-handler?

rberger08:04:36

I don’t know.

rberger08:04:59

It does look like http2 is a node thing not an npm package

thheller08:04:15

upgrade shadow-cljs. that now includes a dependency trace to see who ended up including that package

thheller08:04:24

yes http2 is a node built-in package

rberger08:04:09

Go to 2.8.99? I’m running 2.8.96

thheller08:04:12

the trace I added in .99

rberger08:04:00

The required JS dependency "http2" is not available, it was required by "node_modules/@aws-sdk/node-http-handler/build/node-http2-handler.js".

Dependency Trace:
	omnyway/mock_checkout_page/core.cljs
	node_modules/@aws-amplify/core/lib/index.js
	node_modules/@aws-amplify/core/lib/Credentials.js
	node_modules/@aws-sdk/credential-provider-cognito-identity/dist/cjs/index.js
	node_modules/@aws-sdk/credential-provider-cognito-identity/dist/cjs/fromCognitoIdentity.js
	node_modules/@aws-sdk/client-cognito-identity/dist/cjs/index.js
	node_modules/@aws-sdk/client-cognito-identity/dist/cjs/CognitoIdentityClient.js
	node_modules/@aws-sdk/client-cognito-identity/dist/cjs/runtimeConfig.js
	node_modules/@aws-sdk/node-http-handler/build/index.js
	node_modules/@aws-sdk/node-http-handler/build/node-http2-handler.js

thheller08:04:19

hmm yeah looks deeply nested

rberger08:04:43

Its probably like a handler for accessing AWS APIs

rberger08:04:19

The “modularized” their sdk in version 3.

thheller08:04:19

dunno why its including node though. maybe the package now needs custom build steps?

thheller08:04:59

I don't know much about any of this AWS stuff but this looks like it would be node server-side stuff

rberger08:04:19

This is supposed to be a client library

rberger08:04:39

Ok, well I asked on their github discussion about it. I’ll see if anyone gives me any clues. But googling for this error finds nothing so I suspect there is some interaction with shadow-cljs and their new implementation. I don’t know how many folks are using the latest amplify-sdk and shadow-cljs.

thheller08:04:13

which package do you actually require in your code?

rberger08:04:03

This is what I have in my requre: 

["@aws-amplify/core" :default Amplify :as amp]
   ["aws-amplify-react" :refer (withAuthenticator)]
   ["/aws-exports.js" :default aws-exports]

thheller08:04:21

no time to look into this further right now. you can try :js-options {:resolve {"http2" false}} in your build config

thheller08:04:38

that will make the http2 require just return an empty package

thheller08:04:49

but it looks to me like all of this shouldn't be loaded at all

rberger08:04:18

Appreciate your help! We’ll see if I can get anyone at AWS to give some insight

rberger08:04:34

Looks like :js-options {:resolve {"http2" false}}`` Did the trick!

rberger09:04:06

Thanks again! I sometimes wonder if you are a AI! 😆

4
yenda11:04:41

anyone here using a linter along with a shadow-cljs project such as zprint or cljfmt? how did you set it up (native image? calling it manually or scripted?)

dntn16:04:45

So I have a project that builds using shadow-cljs and one of the dependencies I include is a react component from NPM that includes its own assets that is itself bundled with (using rollup.js). For example, that package has some code like: 

const img = require('my-image.jpg')
// then, later
<image src={img} />
But when build my shadow-cljs project, in the browser, I get: 
 Failed to load app.views.js Module not provided: ./my-image.png
if I include the package with (:require '[my-npm-package]) Some thoughts from a colleague who has looked into this a bit more: > I have a shadow-cljs question for anyone who has worked with it. It seems to do some translation of commonJS's `require` with npm modules, but how do I get it to do the same with relative imports internal to those modules? > That is, it correctly figures out how to load npm modules so that e.g. `(:require '[react])` is equivalent to `require("react")` in plain old javascript. However, I'm working with a module that internally does a `require('./logo.png')`. > Now, `logo.png` is present in the distributed npm package (it sits right next to the js file in question inside `node_modules`) but shadow-cljs cannot figure out how to load it! > ... > I think the issue might just be that shadow-cljs is not intended to be a full asset bundler like webpack. > Other projects are using webpack which is loading (and inlining) the image as a data URI; however your shadow-cljs is not. Let me know if anything isn't clear and I appreciate any insights! 🙂

thheller16:04:37

shadow-cljs has no support for including images that way

dntn16:04:34

Thanks for the confirmation.

dntn17:04:50

@U05224H0W can you speak to whether this is something that shadow-cljs could support in the future (i.e., is within what you consider the scope of shadow-cljs or should it be considered as an external extension as alluded in the CONTRIBUTING doc on github) and, if so, the level of effort it might take? For example, would it be reasonable for me to submit an issue for this on github? Could it possibly be realistic for a new contributor to implement this kind of functionality? I've read https://github.com/thheller/shadow-cljs/blob/master/CONTRIBUTING.md but want to make sure I don't clutter the issues unnecessarily.

thheller17:04:57

shadow-cljs probably will never support this directly. you could do this as a secondary plugin or build hook if you wanted. you don't really need to do anything in shadow-cljs to support this. half of it you can probably do with just a macro

thheller17:04:25

but enough people keep asking that I may reconsider my position on this

jplaza16:04:27

How to know and change the CLJS version used in the project?

thheller17:04:20

don't. I recommend sticking with the version shadow-cljs depends on.

p-himik17:04:01

Will the new CLJS release of 1.10.741 (namely, the JavaScript Bundler Support) affect anything w.r.t. shadow-cljs? If so, what can we expect?

thheller19:04:30

@p-himik no change or impact whatsoever. shadow-cljs already does way more than that so doesn't need any of the newly added stuff.

metal 32
Michaël Salihi07:04:11

Not even for React Native with the new bundle target ?

thheller07:04:17

all the stuff the :bundle enables (and more) has already been supported for years by shadow-cljs

thheller07:04:35

I even think :bundle is a bad idea for the reasons I listed here https://code.thheller.com/blog/shadow-cljs/2018/06/15/why-not-webpack.html

Michaël Salihi07:04:46

OK I will re-read your post about this, thx. I thought it had changed and that it was no longer relevant.

thheller07:04:48

nothing changed no. it is fine to use webpack if you want and I'll document how you can do that with shadow-cljs

thheller07:04:09

but I still don't recommend it and it won't become the default