This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2024-05-03
Channels
- # aleph (62)
- # announcements (44)
- # babashka (2)
- # beginners (72)
- # biff (16)
- # calva (3)
- # clj-commons (4)
- # clj-kondo (2)
- # clojure (217)
- # clojure-brasil (2)
- # clojure-europe (21)
- # clojure-nl (1)
- # clojure-norway (12)
- # clojure-sweden (15)
- # clojure-uk (15)
- # clojuredesign-podcast (14)
- # clojurescript (21)
- # cursive (1)
- # datalevin (1)
- # datascript (4)
- # emacs (13)
- # gratitude (2)
- # helix (7)
- # integrant (5)
- # jobs-discuss (116)
- # lsp (4)
- # overtone (7)
please excuse the cross post, I posted in #C061V0G8Z but no replies: is http://npmjs.com like maven for javascript libraries ? i.e. are the packages there mostly prebuilt and ready to use in the browser (like maven hosts mostly prebuilt jars), or do they need to be built or is it a mixture ?
I don't think JS libs need building as such... as they are distributed as code (as optimised code, so there is a build step involved)
That's not quite correct.
tl;dr: it's a bloody mess and is nothing like Maven.
Some packages provide only the source JS that might or might not need additional postprocessing (e.g. because it requires CSS files in JS code or because it targets features that only one browser has).
Some packages provide only minified JS that doesn't need anything else.
Some provide both or different varieties of either or both, and specify in which context which variety should be used via package.json
.
TS packages might provide the resulting JS + .d.ts
files. Or they might provide only TS files.
JSX is also a thing. And TSX.
Some packages will run executables on your machine during installation.
@U2FRKM4TW thanks, I suspected as much but I was hopeful that it might provide what I needed to write an NPM-free tools.deps resolver tool
is there no common registry in the JS world for minified browser-ready packages then ?
I would be surprised if it existed. It's common for JS libraries to have optional dependencies. Or to have code that becomes dead when some flag is set and is tree-shaken away only during compilation. Or to desire being compiled together with a bunch of other libraries to achieve better minification.
good grief. Well, back to trying Nashorn then...
it was, but it's since been extracted
I want an NPM-free Clojure/Java only tools.deps extension for JS libs
-- don't ask me why or try to convince me otherwise
Frankly, to me that sounds like "I want to turn lead into gold". Well, technically it is possible - we not only know the physics, we even have a few "tools" for that. But it's way beyond "not worth it". Good luck. :) Especially given that you'll have to keep up with the changes in the JS world.
yes I've been told it's not worth it
who do you expect to consume those JS files? I mean nobody is stopping you from putting .js files into .jar files and publishing them via clojars?
ala https://www.webjars.org/ I guess?
I want an NPM-free Clojure/Java only tools.deps extension for JS libsI've been hearing the I-wish-a-NPM-free-promised-land psalm in plain JS land for ages, it seems something maaany really wish to have for good and less good reasons, but probably is enough of a massive chunk of work to not being much likely to happen (more likely to materialise with some actual work rather than wishing somebody else does it)
But isn't that the case with javascript modules or esm. It's like an "NPM" free way to load javascript modules. Afaik a lot of js devs see that as a promised land no clue how it will play out. And regarding esm deno and bun js are the ones that use the esm approach which is not relient on npm.