-
-
Notifications
You must be signed in to change notification settings - Fork 180
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add support for npm cljs module/project #200
Comments
Why? See my comments on anmonteiro/lumo#130 (comment). The only valid argument I have heard for this is that What do you hope to gain? |
It's true that publishing to npm does not have obvious benefits. But please don't underestimate how familiarity matters to us. npm has been running for like 8 years and js developers like me are so familiar with it. If beginners can not manage to share a package online with like one or two days trying Boot or Lein, it will remain a problem. Personally I don't think many of us can do it in a day or two. |
shadow-cljs can install from npm and require js node_moduless now, and if go further, it will attract more JS developers like me. convenience and familiarity matters. |
As I said ... we can solve this by making tooling easier. Nobody said it has to be Boot or Lein. Those are the current options. What if I'm totally on-board adding publishing support to shadow-cljs BUT I currently just don't have the time to do it. Publishing to npm is not free either and would require some work. I also have zero interest in splitting the CLJS community into shadow-cljs and non-shadow-cljs users. The |
In this comment you write:
You criticize webpack loaders as a nonsense because everyone that wants to consume the source from these libraries need to configure these loaders in their own project to consume them. You suggest that jsx should not be distributed but only the precompiled ecmascript. So why should clojurescript be any different? I hate that the typical webpack configuration can be hundreds of lines long to configure loaders for every library they are using. But I also hate that I can't write a javascript library in clojure without forcing my consumers to build it from source using tools they aren't comfortable using. I get that it is not that simple, if you try to bundle two previously minified versions of cljs.core into the same bundle doesn't work you'll just end up with two minified versions of cljs.core rather than one. Some of the same reasons shadow-cljs doesn't want to ship precompiled assets are the same reasons that webpack pushes loader configuration down to the app developer rather than library author -- to get the best results by building everything from source. I don't think there is just one right answer to this, some people like building all there dependencies from source and some prefer the simplicity of precompiled assets. |
ClojureScript is different. ClojureScript has macros which you can't really use from JS. It was also build with the Closure Library and Closure Compiler in mind. I happen to prefer this choice over what was (and still is happening) in the JS world. I worked hard on making the It would take a significant amount of time/effort to rewrite the compiler to generate pure ES6 (or CommonJS). If you leave out macros it is certainly doable but I'm not aware of anyone working on it. |
I would just like to chime in on this (closed) issue. I used nothing but For reference, here's the release on NPM: https://www.npmjs.com/package/citysdk |
Also this thread is 10 months old and deployment tooling hasn't gotten any easier - aka - tooling is hard and nobody has time for it as we all know. On a positive note - deps has a couple of new additions to the pool like https://github.com/slipset/deps-deploy I am using it and it is doing its job. |
usually cljs package is distributed to https://clojars.org/ , but those from JS world is more confortable with npm. and npm support not only js modules, for example, ReasonML module bs-fetch is a npm module.
The text was updated successfully, but these errors were encountered: