Lumo-cljs and Glitch: npm dependencies issue?

Hey there,

Following on from getting Elm running on Glitch, I decided to turn myself to getting Clojurescript going as well. CLJS has a self-hosted compiler in the form of Lumo, which runs on node and the JS port of Google Closure Compiler, in theory letting me run and compilre CLJS on Glitch, yay!

The good news is: I did get ClojureScript compilation with Lumo working.

The bad news is: I can’t get it to work with any NPM libraries. Nor has a days work in conference with a couple other Lumo/CLJS people managed to figure out why. They should work, but they don’t.

You can see the error in action on this project:!/curved-prawn

I’ve opened an issue on the Lumo repo, which you can find here:

But I’m not entirely sure it’s Lumo’s fault. The same code cloned locally will work (though I do use plain npm and a newer Node, as mentioned in the issue), so I’m wondering if it’s something to do with the unique way that glitch handles dependencies (caching, pnpm, linking, and so on). The stack trace actually throws from Google Closure, as you can see from the console in the linked Glitch project.

Any ideas appreciated. I’ll also link here in the issue.

OK, I can now reproduce this locally under Ubuntu/WSL. The issue seems to be caused by however pnpm handles modules that differs from normal npm.

The compiler also throws a fun new error I don’t recall seeing on Glitch that further points to a resolver issue:

    throw err;

Error: Cannot find module 'resolve'
    at Function.Module._resolveFilename (module.js:547:15)
    at Function.Module._load (module.js:474:25)
    at Module.require (module.js:596:17)
    at require (internal/module.js:11:18)
    at [eval]:4:19
    at ContextifyScript.Script.runInThisContext (vm.js:50:33)
    at Object.runInThisContext (vm.js:139:38)
    at Object.<anonymous> ([eval]-wrapper:6:22)
    at Module._compile (module.js:652:30)
    at evalScript (bootstrap_node.js:466:27)

You can run ‘enable-npm’ from the command line if you want to use npm rather than pnpm. The downside is then your dependencies count towards your project disk space.

Ahh, damn. Yeah. All the deps needed for Lumo together seems to require too much space. Error: ENOSPC: no space left on device, write.

Ah, that’s a shame. I suggest creating an issue with pnpm - they’re always amazingly responsive.

I posted an issue with pnpm here:

also, incidentally, can you turn off enable-npm or is it irreversible?

Great! Thanks for doing that. You can run enable-pnpm and it’ll switch back to that.

Further update on this with the pnpm folks. Running pnpm install --force --shamefully-flatten fixes the issue locally.

I’m not able to really apply this fix on Glitch, however. I can go into the console, delete the node_modules and try to run that manually, but it makes no difference.

Is it caching the dependencies somehow, or something to do with the automation? Is it possible to set flags for the pnpm install that runs automatically on a project instance?

So I just remixed!/curved-prawn but I couldn’t reproduce your issue… what are the steps needed to see the error? :slight_smile: thanks!

In theory, you should just run the Glitch, and check the developer console in the resulting site to see that the library is missing.

However now I’m seeing a new error, that persists even in a remix:

      throw er; // Unhandled 'error' event

Error: spawn /rbd/pnpm-volume/8bdb4a2b-4c09-4187-ad73-ce09f75a7d9d/node_modules/ ENOENT
    at _errnoException (util.js:992:11)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:190:19)
    at onErrorNT (internal/child_process.js:372:16)
    at _combinedTickCallback (internal/process/next_tick.js:138:11)
    at process._tickCallback (internal/process/next_tick.js:180:9)
    at Function.Module.runMain (module.js:695:11)
    at startup (bootstrap_node.js:191:16)
    at bootstrap_node.js:612:3

I can’t get the site to run at all now.

EDIT: And it seems to be working again now.

I think this might be related to how we cache the npm packages, as you have hinted. If it occurs again to you, this might fix it (let us know!): create the file /app/.npmrc, and write this line in it:


It might make the install step a bit slower, but in turn it should fix your issue :slight_smile:

Hmm. I’m not sure which issue now that’s meant to fix :laughing:

The ENONT issue on my last post has gone away on its own, but the .npmrc fix seems to have no effect on the dependencies problem.

I was referring to the dependencies problem. So you still get the same issue even when that line is added? :confused:

Yep. Same nameToPath error as before.