Hello. I am writing a program with output to the browser. For it (besides rubygems) you need several dependencies: CSS, fonts, JavaScript library. It is necessary to organize the management of dependencies, first of all, at least downloading by command. The options that I came up with:

  • This can be organized by Bower, but since the program is distributed, I would not like to force users to install Node.js in addition to Ruby only to download dependencies.
  • You can distribute it directly with the program, but the program will be in Open Source on GitHub, and thrusting other people's projects into your repository, even with a disclaimer, is somehow inconvenient. Plus, you will have to monitor the versions of each library and make a separate commit for each version of each dependency.
  • You can do this through Rake + GitHub + Net :: HTTP + File.write, but this is somehow unreliable and will take an extra bunch of code that needs to be maintained.
  • Gem wrappers are known to be almost never updated by anyone.

There are a couple more ideas, but at the moment they do not seem feasible:

  • Bower, alas, does not provide a public Web API
  • CDN is not an option, since the program is again distributed and should work without an internet connection.
  • Gem for this task did not find (more below)

I also tried to look for a gem, but the results are deplorable:

  • giternal and rip allowed to load dependencies with git repositories, but they have not been supported by anyone for a long time and do not pass most of the tests.
  • rails-assets and torba only for sprockets, but I don’t want to rewrite the whole project under a gem, which, to put it mildly, I don’t like at all.
  • "rails-assets and torba only for sprockets" - that is, in your project you use a build system different from sprockets? If so, which one? And is there any stable and appropriate dependency management system for this build system? - Vitaly Emelyantsev
  • Vitali, I do not have an assembly system: the project on Sinatra and the files are given to the client in the same form that lies in the file system. Therefore, I cannot use the sprockets layout format: as far as I understand from the fact that I installed torba, it implies a bunch of random characters after the dependency name in the directory names. - Juickl 5:53 pm
  • Sprockets does so, yes. And this is good - it ensures that when updating styles and scripts, users will download updated versions of files. Without these random characters (called fingerprint and assets digest) there is a high risk that even after updating the site, users will load old browser-styleted scripts and scripts. - Vitaliy Emelyantsev
  • In any case, whether this is a good method or a bad one, I need to get styles and scripts without it: I will manually connect the styles, and with the fingerprint, everything will fly off on the first update. - Juickl
  • 2
    @Juickl given the general inclination of the gentlemen front-line workers to streamline the development of assets through NodeJS, I would just put it in the requirements. After all, as you yourself noticed, this will be required only for those who want the most fresh , and not a packaged release, and may want to finalize the assets. - D-side

1 answer 1

In the frontend, Node.js is firmly rooted to build and transform everything. Therefore, to require the Node.js installed to modify assets, this business is now quite common. Therefore, for a complete development environment for your project, Node.js is still needed . Run away from him is useless - catch up.

The main task for you is “not to force end users to install Node.js, since it is no longer needed at runtime” . But the end users will more likely take the finished assembly, than they will do it themselves, and if the assets are already assembled in the finished assemblies, then they will not need Node.js either. Therefore, the problem has already been solved.

git clone not intended to distribute assemblies. That's it at all.

If you are nervous about the need to force, even for the sake of developing the server-side part, to install dependencies of assets, then you can make a knight's move and put them into a separate heme . And when generating configs for a web server (or configuring the built-in), you can find out where the heme with assets is installed (using the example of activesupport ):

 # они работают немножко по-разному, вас интересует скорее первое Bundler.rubygems.find_name('activesupport').first.full_gem_path Gem::Specification.find_by_name('activesupport').gem_dir

This may make sense where the assets and the server part are very loosely connected with each other, if the assets form something SPA-like, for example.

And, accordingly, the previous solution works: you pack releases of assets in advance, and who needs to be engaged in development can optionally deliver already packaged ones.