Git Product home page Git Product logo

Comments (7)

alandipert avatar alandipert commented on September 15, 2024

I feel good about this, and would propose boot/cljs/includes where the convention is boot/<task>/<task-specific-dirs>

I was ruminating a bit recently about how if we supported boot/bin we could generate PATHs that pointed to binstubs, so that tasks/programs could be invoked directly from shell without the boot leader. boot would make it really easy to distribute executables over Maven, which isn't currently done.

from boot-cljs.

micha avatar micha commented on September 15, 2024

I like this plan, too. +1

Why not adzerk/boot-cljs/includes though? Seems like asking for trouble to have anyone in the world using the boot subtree, when they already have a well defined subtree of their own as established in Maven.

from boot-cljs.

martinklepsch avatar martinklepsch commented on September 15, 2024

@micha I'd like it to be something that is really not tied to anything but boot (i.e. hoplon or adzerk). Forcing people to create a directory with a seemingly arbitrary name seems confusing to me.

If we can agree on a directory in the next hour or so I'll make a PR today. :)

from boot-cljs.

pandeiro avatar pandeiro commented on September 15, 2024

when i first saw it (hoplon/includes), it seemed out of left field. imo just 'includes' would be a sane default and some sort of configurable :includes key that could point to a specific directory would be most ideal.

but i still think manually fetching JS and CSS is a little bit old-school when webjars exists -- couldn't one build upon that, to get js deps the same way one gets clojure/jvm deps?

from boot-cljs.

micha avatar micha commented on September 15, 2024

I think there is a problem using a namespace you don't own as a convention in JARs. I chose the hoplon/include subtree because we at least own that, so it won't conflict with anything else on the classpath. Choosing boot/<task>/... might cause problems, if for instance there are two tasks with the same name. In general I think namespacing things in JARs makes good sense.

I think no matter what you do you're going to be asking people to put things in an arbitrary place, just like the .cljs file extension is arbitrary. It seems reasonable to namespace the files under adzerk/boot-cljs, because that's the task that's going to be handling them. In the JVM world the subdirectory namespacing thing is pretty universal, so we can be pretty confident that this would avoid possible conflicts.

I think it's important to choose the subdirectory well because that's "magical" information that only the task knows about. That is to say, the significance of files in that subtree is only known by the adzerk/boot-cljs task.

from boot-cljs.

martinklepsch avatar martinklepsch commented on September 15, 2024

There has been some more discussions about this on IRC and the conclusion was to create a separate org that contains repositories that package up these jars. This way the directory discussed here could be cljsjs/includes or something like that.

The org is here: https://github.com/cljsjs

I'm currently working on packaging react and creating some tasks that aid this kind of packaging process including packaging multiple variants (with classifiers) with a single boot task. I'm writing this task for boot-2.0.0-rc1 here: https://github.com/cljsjs/react and will put it into a separate repo when I managed put something useful together.

from boot-cljs.

martinklepsch avatar martinklepsch commented on September 15, 2024

Ok, so I got that working kind of nice I think. If you clone https://github.com/cljsjs/react
you can run the following (note that this is built against the tempdirs branch):

$ boot package
$ boot package -v min
$ boot package -v addons
$ boot package -v addons-min

When appending `push to these commands they should get deployed to clojars.

Currently the generated jars adhere to the structure as described in the boot-cljs Readme (hoplon/includes). As I'd like to also support the use of these jars with lein-cljsbuild I'd like to avoid changing the directory structure later on.

The directory structure I had in mind was cljsjs/includes/react/. Is that a good choice? I'm not overly familiar with what kind of conflicts can occur so any help on getting this right would be great.

Also is there a way we can support this directory structure in boot-cljs at least temporary until the collection of JS dependencies is split up into another task?
Another alternative might be to add some Clojure file that defines some vars like cljsjs.react/includes, cljsjs/externs, cljsjs/libraries. These vars could be required in a project.clj and used as arguments to :cljsbuild. This would also make it easier to update dependencies as you'd only have to change the version number in the dependency itself.
Probably the latter is the better option.

Any thoughts?

from boot-cljs.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.