How to build a single Js file with all JS.Class modules?

[Francesco Belladonna]

I'm trying to build an automatic builder for JS.Class to allows include it in my rails app through a gem. I want to give users the opportunity to include whole library with a single line (//= require js.class.all), however I don't know how can I run jsbuild to get ALL modules and include them. I don't know the name of all classes and I'm not sure if it's a good idea to manually list all files.

Any suggestion on how to achieve this?

[James Coglan]

On 2 February 2013 03:06, Francesco Belladonna <francesco....@gmail.com> wrote:

I'm trying to build an automatic builder for JS.Class to allows include it in my rails app through a gem. I want to give users the opportunity to include whole library with a single line (//= require js.class.all), however I don't know how can I run jsbuild to get ALL modules and include them. I don't know the name of all classes and I'm not sure if it's a good idea to manually list all files.

When you say 'through a gem', what exactly do you mean? 

[James Coglan]

On 2 February 2013 03:19, Francesco Belladonna <francesco....@gmail.com> wrote:

I mean that I would like to put the gem in my gemfile so I can easily keep js.class up to date and always be compiled for my project.

Are you saying that you're writing a gem that relies on JS.Class, or are you trying to package JS.Class itself as a gem?

 

I'm almost there but I really don't know how to run jsbuild to include all modules, as I've said my only idea is "jsbuild JS.Module1 JS.Module2... --no-packages" but I don't know where to fetch a list of classes, so my idea was to use files, but they should be included in the right order and I don't know how to find except from parsing javascript.

Including all the modules is hugely wasteful, not least because about half of that code will be the test framework. The whole package will come to a few hundred kb, most of which you're probably not using.

As for ordering, this is exactly what JS.Packages is for -- list your dependencies in there, and jsbuild will figure out which modules you need and what order they need to be in.

[Francesco Belladonna]

Well, skipping test is ok. Yes I would like to bundle js. Class itself as a gem. At the moment I want to just include all, but the next step should be to inject jsbuild in asset pipeline and configure package with an yml file.

--
You received this message because you are subscribed to the Google Groups "jsclass-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jsclass-user...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[James Coglan]

On 2 February 2013 03:39, Francesco Belladonna <francesco....@gmail.com> wrote:

Well, skipping test is ok. Yes I would like to bundle js. Class itself as a gem. At the moment I want to just include all, but the next step should be to inject jsbuild in asset pipeline and configure package with an yml file.

What's the advantage of packaging it as a gem, compared to just downloading the JS and putting it in your project, or installing it with npm?

I still think, even if you left out test.js, the resulting bundle will be full of stuff you don't need. I've tried to make it easy for you to package just the stuff you do need, along with the rest of your app, using jsbuild. If there are usability problems with that I'd rather fix them in JS.Class itself rather than having it wrapped in a Ruby package. My experience with these JS gems is they just introduce obfuscation with no real benefit compared to just downloading the JS directly. 

[James Coglan]

On 2 February 2013 03:39, Francesco Belladonna <francesco....@gmail.com> wrote:

but the next step should be to inject jsbuild in asset pipeline and configure package with an yml file.

Aside with the problems with YAML per se, I'd counsel against this approach. JS.Class tries to let you do everything you need to -- especially loading modules -- just using JavaScript. The reason is that this makes your JS setup independent of your server stack, letting you use the same configuration to run tests on a static page as you do to load your code in production. Having the config confined to a server-specific file format defeats this goal.

See this blog post for more info on how I think you should structure apps:

http://blog.jcoglan.com/2012/01/23/organizing-a-project-with-js-packages/

[Francesco Belladonna]

Well, the biggest advantage is that I have just to edit a single
configuration file (an yml) to add other js.class packages, then the
gem will compile them for me, instead of going back to terminal,
compile everything again (and I have to "store" somewhere the last
line i've used to compile, for example if I used "jsbuild JS.Set" the
next time I have to use "jsbuild JS.Set JS.SomethingElse"), copy/paste
into project (this can be avoided with a simpler script) and run. Also
one important thing is that the gem should provide an helper where if
you are in a production environment, will use the "static" loading
(modules bundled into a file), but if you are in a development
environment (or even test) will load files dinamically using the
loader.

I can avoid merging all modules toghether at this point, you have
explain good reasons anyway.

I'm studying how to inject into rails pipeline at this point

2013/2/2 James Coglan <jco...@gmail.com>:

[James Coglan]

On 2 February 2013 14:10, Francesco Belladonna <francesco....@gmail.com> wrote:

Well, the biggest advantage is that I have just to edit a single
configuration file (an yml) to add other js.class packages, then the
gem will compile them for me, instead of going back to terminal,
compile everything again (and I have to "store" somewhere the last
line i've used to compile, for example if I used "jsbuild JS.Set" the
next time I have to use "jsbuild JS.Set JS.SomethingElse"), copy/paste
into project (this can be avoided with a simpler script) and run. Also
one important thing is that the gem should provide an helper where if
you are in a production environment, will use the "static" loading
(modules bundled into a file), but if you are in a development
environment (or even test) will load files dinamically using the
loader.

I would much rather we make these things as easy as possible in cross-platform JS. The build step should be as easy as putting a Make (or Rake or whatever) task in your project with the modules you want.

You can do this in JS.Packages by making an 'App' module that depends on all the others, as in my blog post. Then you just run `jsbuild App` to bundle all your code.

Likewise, the selection of whether to load individual files or a bundle can be done by conditionally defining modules in JS.Packages. This is why the JS.Packages API is JavaScript rather than a static configuration format.

My concern here is that this is a project that's explicitly designed to be cross-platform. Wrapping it up in Ruby introduces a level of obfuscation that makes it seem coupled to Rails, when it's really not. It damages the user experience by making it seem hard to use the library outside of Rails. For example, if you install it with a gem, you can now only load it through the Rails asset pipeline, which makes it much harder to load, say, the test framework on a static page or under PhantomJS.

There are better ways to achieve your aims that don't have the cost of coupling the library to Rails. Let's figure out what they are and get them documented so that non-Rails users get the benefits as well. 

[Francesco Belladonna]

Well but my point was to simplify the job specifically for rails
users, I am doing a rails gem specifically because I would like to
make faster the download/keep updated/keep compiled with correct
modules. Your package already does what you said I think, I was just
bundling everything for rails users.

Anyway, the dependency on node.js will give me some problems on the
production server (I compile assets directly there), so I don't think
I can keep working (I can't install node.js there I think).

2013/2/2 James Coglan <jco...@gmail.com>:

[James Coglan]

On 2 February 2013 14:44, Francesco Belladonna <francesco....@gmail.com> wrote:

Well but my point was to simplify the job specifically for rails
users, I am doing a rails gem specifically because I would like to
make faster the download/keep updated/keep compiled with correct
modules.

And I'm saying we shouldn't have something just for Rails users. It should be clear how to do everything you want no matter what server stack you have, so let's fix that instead.

I'm not sure how this will make it easier to keep up to date if people have to wait for you to package a new gem every time I ship a new release. Better to go straight to the source for that, I think. 

[Francesco Belladonna]

Well, I've built a rakefile that download your gem, build with jake,
and so I have updated files ready in a directory, then I were just
copying them in vendor folder and the gem is ready, so really it does
need a single command.

Now I'm trying to follow your post, let me see what I can find. I'll
try with a big rakefile directly on my server to run jsbuild on a
manifest file, it's a valid option I think

2013/2/2 James Coglan <jco...@gmail.com>:

[James Coglan]

On 2 February 2013 14:53, Francesco Belladonna <francesco....@gmail.com> wrote:

Well, I've built a rakefile that download your gem, build with jake

Why do you need to build it with jake? Are you using the git repo instead of downloading from jsclass.jcoglan.com? 

[Francesco Belladonna]

Yes, so it auto-updates my directory with a simple command. If it's a
problem I can download it straight from the website, but I'm a fun of
autoupdate °°

2013/2/2 James Coglan <jco...@gmail.com>:

[James Coglan]

On 2 February 2013 14:57, Francesco Belladonna <francesco....@gmail.com> wrote:

Yes, so it auto-updates my directory with a simple command. If it's a
problem I can download it straight from the website, but I'm a fun of
autoupdate °°

Okay, well if you've considered my advice and decide to go ahead with the gem anyway, please *only* use downloads from jsclass.jcoglan.com. I am not being held responsible for supporting work-in-progress code from git.

In fact, shipping in-progress snapshots of JS.Class to end users will really damage its user experience. I work very hard to keep my projects stable between releases and that goes out the window if people beging shipping git snapshots. 

[Francesco Belladonna]

In my last e-mail I wrote I were not going to use the gem so, still I
want a rakefile to handle updating for myself.
Anyway, I'm using git for autoupdate, but if you says me that could be
problematic I can just create a script to download it directly from
the website (and unzip it) every time there is a new version (by just
checking the file name), I don't think it's a big problem.

I'll drop gem so, removing it right now from github.

2013/2/2 James Coglan <jco...@gmail.com>:

[James Coglan]

On 2 February 2013 15:04, Francesco Belladonna <francesco....@gmail.com> wrote:

In my last e-mail I wrote I were not going to use the gem so, still I
want a rakefile to handle updating for myself.

Ah okay, sorry for my misunderstanding. If it's just for your project, do whatever you want. I just don't want half-finished code redistributing as libraries, that's all.

Like I said, if it's painful to use, please tell me and let's see how we can improve things in a way that benefits all users, not just Rails users.

I hope I've not come across as discouraging, I'm just trying to make sure we solve problems in the right place.

[Francesco Belladonna]

No problem, I'm not so good in English so I expect people can
misunderstand me quite easily.

I'll let you know how's going. Anyway the "biggest" suggestion I can
give (you can ignore it), just build a repository for js.class builds
that is the same version as the website (and it only contains the
files in "build" directory), so people can write a script to update
their code in easier way (downloading from http and unzipping is just
more lines of code). Also you can avoid some bandwidth usage in this
way (but I imagine is not a problem for you).

I don't think it's painful to build JS.Class, but it's a bit harder to
understand how you handle the project with package manager for
production environment, that post fixed this "issue".

Thanks a lot.

2013/2/2 James Coglan <jco...@gmail.com>:

[James Coglan]

On 2 February 2013 15:17, Francesco Belladonna <francesco....@gmail.com> wrote:

I'll let you know how's going. Anyway the "biggest" suggestion I can
give (you can ignore it), just build a repository for js.class builds
that is the same version as the website (and it only contains the
files in "build" directory), so people can write a script to update
their code in easier way (downloading from http and unzipping is just
more lines of code). Also you can avoid some bandwidth usage in this
way (but I imagine is not a problem for you).

You can install it through npm -- at least that way if you want the latest you just run `npm install jsclass` and you don't have to query for version, etc. This will get you the same contents as the website download, for the most part.

Would it help for me to make a URL on the website that always returned the latest release as a .zip?

I don't think it's painful to build JS.Class, but it's a bit harder to
understand how you handle the project with package manager for
production environment, that post fixed this "issue".

Glad you found that helpful :)

[Francesco Belladonna]

If there is already the npm, I think you've already done it, just I
didn't think about using it. The zip file can be helpful, but I think
that you've already done the job with npm, thanks anyway.

I'm preparing another question (in a separate thread), see you there ;)

2013/2/2 James Coglan <jco...@gmail.com>: