Skip to content
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

Closed
jinwei233 opened this issue Feb 11, 2018 · 8 comments
Closed

add support for npm cljs module/project #200

jinwei233 opened this issue Feb 11, 2018 · 8 comments

Comments

@jinwei233
Copy link

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.

@thheller
Copy link
Owner

Why? See my comments on anmonteiro/lumo#130 (comment).

The only valid argument I have heard for this is that npm publish is easier than publishing clojure(script) libs to clojars/maven. We can solve this by making the tooling easier.

What do you hope to gain?

@tiye
Copy link
Collaborator

tiye commented Feb 11, 2018

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. brew install nodejs, npm login, npm publish, .npmignore, npm ls, tree node_modules/pkg-x, README files, these knowledges like js packages we have already and want we to use them in new journeys. It also means lots of time and effort migrating to new tools like Boot or Lein.

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.

@jinwei233
Copy link
Author

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.

@thheller
Copy link
Owner

It also means lots of time and effort migrating to new tools like Boot or Lein.

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 shadow-cljs publish was a thing? Would it really matter that you didn't type npm publish or where the package ends up?

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 npm support already is problematic enough.

@kurtharriger
Copy link

In this comment you write:

The problem I have with loaders is the .jar situation. Say you write a CLJS library but want to write some React Components in JSX for whatever reason. You publish the library with the .jsx files. Now everyone wanting to consume this library must configure the loader to be able to use your library. That is nonsense and the .jar should only contain the file after JSX processing (just like npm).

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.

@thheller
Copy link
Owner

So why should clojurescript be any different?

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 npm world accessible from ClojureScript. Making ClojureScript accessible from npm is an entirely different story and would require a completely different tool.

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.

@loganpowell
Copy link

I would just like to chime in on this (closed) issue. I used nothing but shadow-cljs during my deployment process and it was a breeze to publish the resulting release to NPM.

For reference, here's the release on NPM: https://www.npmjs.com/package/citysdk

@arichiardi
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants