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

CLJS Support #16

Open
gtrak opened this issue Jan 13, 2014 · 4 comments
Open

CLJS Support #16

gtrak opened this issue Jan 13, 2014 · 4 comments

Comments

@gtrak
Copy link

gtrak commented Jan 13, 2014

Would you welcome CLJS support?

I've got a working proof of concept in my branch, relying on a dumped compiler analysis file, the generation of which will potentially make it into cljs soon. However, it could also be used with runtime-available data.

Screenshot:
http://i.imgur.com/BrAc61U.png?1

Diff:
https://github.com/gtrak/autodoc-cljs/commit/0c4bcf15345c8268ac83eb247e5c94da689fd47c

It's not quite ready for a proper pull-request, but I wanted to know if I should work towards a proper integration.

Here's a related issue I filed with lein-cljsbuild, which I hacked in order to generate the dump.
emezeske/lein-cljsbuild#283

@tomfaulhaber
Copy link
Owner

I am completely in support of CLJS support in autodoc.

My only real concern has to do with maintainability. That is, I worry that changes on the CLJ side might break stuff on the CLJS side and vice-versa. Unfortunately, autodoc has no real tests to prevent this in a systematic way.

However, I don't think this should stand in the way of moving forward. We can think about how to add tests that aren't too brittle as we go along.

So, have at it!

On Jan 13, 2014, at 2:22 PM, Gary Trakhman [email protected] wrote:

Would you welcome CLJS support?

I've got a working proof of concept in my branch, relying on a dumped compiler analysis file, the generation of which will potentially make it into cljs soon. However, it could also be used with runtime-available data.

Screenshot:
http://i.imgur.com/BrAc61U.png?1

Diff:
gtrak@0c4bcf1

It's not quite ready for a proper pull-request, but I wanted to know if I should work towards a proper integration.

Here's a related issue I filed with lein-cljsbuild, which I hacked in order to generate the dump.
emezeske/lein-cljsbuild#283


Reply to this email directly or view it on GitHub.

@venantius
Copy link

It's been quite a while since this issue was opened, but it would be great to see some movement on this. In particular, the ClojureScript project itself would love to have autodoc for generating documentation for its cljs.*.api namespaces (see http://dev.clojure.org/jira/browse/CLJS-1446).

This will require support for both .cljs and .cljc files.

I'm not really sure how to go about approaching this as I ran into some unrelated issues when trying to build the current version of Autodoc, but I'll file a separate issue for that.

@tomfaulhaber
Copy link
Owner

I agree, but I'm not sure that @gtrak was on exactly the right track.

Here's how I would think about it:

  1. Create a autodoc-collect variant that processes cljs files (and cljc files handled as clojurescript). It should produce an identical data structure to that produced by autodoc collect.
  2. Teach autodoc to be smart about whether to call autodoc-collect, autodoc-collect-cljs, or both (the new tools.namespace should help a lot here).
  3. Merge together the output of the two programs (especially interesting for cljc files).
  4. Modify the output format to indicate language variant when two variants exist.

A slightly different approach would be to make autodoc-collect smart enough to handle both languages. This is dangerous, though, since autodoc-collect is specifically designed to handle clojure versions all the way back to v1.1 and is, therefore, pretty limited.

As I mentioned above, I am happy to have contributions in this area. One thing that would be a huge help work on the ClojureScript version of autodoc-collect. My expertise on the mechanics of ClojureScript is weak and not likely to get a lot better in the near future, so that would accelerate this issue a bunch.

@venantius
Copy link

I'm inclined to agree that a new approach may be needed. At the moment my familiarity with ClojureScript is still pretty weak as I only started tinkering with it a week or so ago, so I'm probably not the right person to take this on. If that changes I'll come back :P

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

3 participants