I'm working on a little web application using Express.js, Backbone.js, Bootstrap and some others. I've decided to give Bower a try to manage the front end components for this one, but after installing the packages, I noticed that all of them installed tons of stuff that I don't need at all, like LESS files (Bootstrap) or QUnit tests for the framework (Backbone), README.md files, documentation source code, and so on:
As you can see, it's absolute madness in here.
I've searched the package index a bit and I've found a leaner version of Bootstrap called bootstrap.css, but after installing I noticed it is still version 2.3.2, so pretty much outdated.
Isn't there a way to install up to date dist versions of all those libraries?
The idea of having a package manager is nice but it seems a bit off putting to have my application source bloated with all this stuff. I most definitely do not need the Backbone documentation installed on my web server.
This is a matter of package authors not configuring their bower.json to ignore those extraneous files and folders. Additionally, not all package authors configure their bower.json to list the main file(s) for their package.
You can see how without having those two pieces of information-- what files aren't needed, and which ones are the "main" files-- Bower, or any other tool, can't reliably guess what is necessary and what is junk.
As far as it bloating your server; ideally, you shouldn't be committing Bower components. You would have a build process that takes your source files, wherever they may be on disk, and morphs them into one minified file.
You can try bowercopy.
What does it do?
Download all the bower components listed in bower.json
Copy files you need to specified folder
(Optional) Remove the bower_components folder.
Every time you run the bowercopy task, it will do the process above.
A grunt config example
bowercopy: {
options: {
destPrefix:'app/jslib', // Here is the dest folder
clean:true // It's optinal
},
dist: {
// List all the files you need here
src:'backbone/backbone.js' // "src" can be an array
}
}
Yeah, You have to specify all the files you need one by one. But it does achieve your goal.
Related
In grails 2 and earlier, plugins installed their source to .grails/<version>/projects/<projectName>/plugins/etc, this made it easy to debug plugins that were installed without having to check out and load the full source... find where problems were that could be hot-deployed. No need to install run the plugin locally.
In grails 3, this seems to be missing... or maybe I'm just missing something? Is there somewhere in my project I can directly modify the plugin source without checking out the plugin, compiling it and then installing it locally?
Yes, you're missing something rather important :)
Grails 2 plugins are distributed as ZIP files including source code, but Grails 3+ plugins are distributed as JAR files with the code compiled into classes. This has multiple benefits over the earlier approach, the biggest one being that you can no longer edit the source directly (which is the worst way to make changes to how a plugin works).
What you should do instead (in all versions of Grails) is to take advantage of the compilation/load/resolution order between the app and the installed plugins - plugins load first, then the app. This allows you to override nearly anything in a plugin just by creating a file (Groovy/Java/GSP/etc.) with the same name and same relative location in your app code, and it will automagically override the plugin's file or class. E.g. to override a plugin's com.foo.BarController controller, create grails-app/controllers/com/foo/BarController.groovy in your app (manually or by copying the original source and modifying it).
I am building a Spring project with Bower to manage client libraries. I am interested to know what is the best practices way to expose those libraries (or any sort of client libraries managed by a package manager) to the web client.
I can see that I can use a .bowerrc file to choose where to install the files. I could have them install into a static resources folder, one where each of the files installed would be accessible to http requests. It struck me as a potential code smell, however, to expose all the files, instead of the ones that I specifically need.
I could copy individual files into such a directory, or adopt an automated solution to do the same. If this is not considered necessary, however, I would prefer not to expend the effort.
Which of these, or any other solution (if any) is considered the clear best practices way to do this and why? (Please provide a reference to support your answer.) To be clear, I am not interested in individual opinion, but rather if there is a known, clearly preferred, solution.
After looking at what a lot of projects and tutorial suggest, it seems that the clear way to do this is the following:
Use a framework like Grunt or Gulp to separate "built" code from source code. Built code, in this case refers to code that is copied, minified, and/or concatenated into a separate folder. The Grunt or Gulp configuration file should include all application code, as well as select source files from bower components. The running application should reference only these "built" files. The directory of "built" client-side code should be served statically by Spring.
(and why do you think the jQuery team are unable or unwilling to write decent documentation?;)
For example, go to http://jqueryui.com/download/all/ and download either
jQuery UI 1.10.3 (source, demos, themes, tests)
jQuery UI 1.10.3 Themes
#1
There is a MANIFEST file.
There is a README.md file but no explanation of the the layout of the archive.
There are several files with a JSON extension e.g. ui.accordion.jquery.json. They contain some information about the particular UI widget. I don't know what these are used for, do you know?
A file named package.json. It seems just to be some library info in JSON format. Do you know what this is for? I suspect it's linked to the other .json files, but who knows?
There is an directory named external that holds javascripts. Do you know what this is for?
There is the jquery-1.9.1.js file. No minified version.
A licence in MIT-LICENSE.txt.
An AUTHORS.txt file, which contains the names of the contributors, that are repeated several times throughout the archive. Not one of them managed to list what's in the archive thoroughly though ;)
A demos directory with what appears to be all the demos from the website.
A Gruntfile.js that the README says is used to build jQuery. Whatever "building" jQuery means.
A tests directory.
There is a directory named ui that seems to hold all the jQuery UI effects javascripts, also minified in a subdirectory, and an i18n subdirectory for those widgets that need internationalization.
There is a directory named themes. In it there is a subdir called base that holds the base theme stylesheet. This subdir also contains an images dir for the base theme. It also holds stylesheets for several of the effects e.g. jquery.ui.accordion.css. Do these only work for the base theme or can they be applied to any theme? If not, why does only base have them? (see below) There is also a minified subdir which has minified versions of all the stylesheets.
#2
The archive contains a MANIFEST file
but no README.
An AUTHORS file.
A package.json file with a small amount of information about the project.
It has several themes but no base.
There are no effects/widget files in either the root directory or each of the themes' directories.
Each theme directory contains an images subdirectory with image files associated with that theme, a jquery-ui.css stylesheet, a minified version of this, and a jquery.ui.theme.css. The jquery-ui.css in each theme directory is different to each directory. Do you know what each of these files is for? Why aren't all the specific changes in the jquery.ui.theme.css file?
Why do I need to know this?
This may come up in the comments so I'll answer it here. I've written a couple of libraries to help with deploying the correct version / theme in Ruby Rack projects, Rack JQueryUI and Rack JQueryUI Themes. Every time there's a version change of jQuery UI I have to deal with these undocumented archives, that also seem to change in layout / contents between versions. I've not had good feedback when speaking with the jQuery team - I find they are lamentable at documentation and it's obviously not a priority for them, they'd rather be renaming functions or something - so I'd rather just have someone helpful answer me here, and this will make a good place to keep it (out of their reach, so to speak).
I'm most interested in the questions around the theme directories as that will directly help me right now, but I've extended the scope of the question because I believe it will help others and I am curious.
Let's start with an explanation of what jQuery UI downloads are: They're a full bundle of development and production files. Keep in mind that jQuery UI is downloaded over 11,000 times per day (and that's just the download builder usage). The ways in which these downloads are used can vary greatly among users. The contents of these downloads are intended to serve the largest number of users. It's important to note that the development bundle is almost an exact copy of the source repository.
source, demos, themes, tests
MANIFEST: This is a file containing a list of every other file in the zip, along with checksums. Very few users will care about the manifest, but for those who do care, it provides critical information.
README.md: (note that you listed README.txt): This is the README for the jquery-ui git repository. It's an exact copy of what you will see if you view the project on GitHub.
*.json: These are plugin manifest files for the jQuery Plugin Registry. These files are never stored in the master branch (or any other branch), but are always included in tags. Because they provide useful information, they're included in the downloads. You can read more about the manifest file structure.
package.json: package.json is a standard file for use with npm/node. All jQuery projects rely on node to do linting, testing, builds, releases, etc. This is completely separate from the other JSON files which are for the jQuery Plugin Registry. They have very similar structures, because the plugin manifest files were designed based on npm.
external: This directory contains third party scripts which are used in demos and tests.
jquery-1.9.1.js: This is the latest stable version of jQuery that jQuery UI was tested against. We never include minified jQuery versions in the jQuery UI repository since they're horrible for debugging.
MIT-LICENSE.txt: The license which defines the terms under which you can use the files in the download.
AUTHORS.txt: A list of contributors to the jquery-ui repository. This does not include contributors to other parts of the jQuery UI project, such as work on any of our various sites or documentation.
demos: A directory of demos for the selected components (in this case all components). The demos actually originate in the jquery-ui repo and are copied to jqueryui.com during releases.
Gruntfile.js: We use Grunt for linting, testing, and building. Grunt is a JavaScript task runner for node. Building jQuery UI means minification and concatenation.
tests: A directory of tests for the selected components (in this case all components).
ui: A copy of the source files, with #VERSION replaced with the release's version number. The jquery-ui.js file is generated during the build by concatenating all of the source files together. The minified directory is generated during the build by minifying the individual files. And of coure jquery-ui.min.js is generated by both concatenating and minifying the source files.
themes: A copy of the source files, with #VERSION replaced with the release's version number. This undergoes the same process as the ui directory regarding concatenation and minification. The individual component files are theme-independent. So jquery.ui.accordion.css will work with any theme. These are the required CSS files for use with the JS files. You can build any theme you want, but if you don't use the functional CSS for the component, then nothing is guaranteed to work. Full themes (what pretty much all users actually use), contain all of the functional CSS plus the theme CSS in a single file.
themes
Themes are generated by ThemeRoller. They do not live in any repository and as such do not contain artifacts of any repository. This is why there is no README.
MANIFEST: Same as above, the manifest contains checksums for the files in the download.
AUTHORS.txt: A copy of AUTHORS.txt from jquery-ui. This should exactly match the source download. While this isn't a list of people who have contributed to themes, we view this as part of the code and include the same list of authors.
package.json: A copy of package.json from jquery-ui. This file does seem a bit strange, since it's not coming from a repository. We should probably remove this.
themes: A directory of generated themes. These do not contain the source variables/tokens. The base theme is not a generated theme and therefore is not included. You'll notice that generated themes also have a different directory structure. Each theme contains three files: jquery.ui.theme.css is just the theme CSS; this is what can be used with the functional CSS provided in the base theme. jquery-ui.css is a full theme; it includes the theme CSS plus the functional CSS. jquery-ui.min.css is a minified copy of jquery-ui.css.
jQuery UI has decided to simplify its package (extremely) in order to help avoid confusions such as the above. From 1.11 and on, we distribute
https://github.com/jquery/download.jqueryui.com/pull/214. On any new questions just let us know.
I am starting to try out Bootstrap. I have already downloaded the dotless extension but I am confused as to what to do next. Looking at the bootstrap files I see a lot of .less files. Can someone explain where I should put these within the MVC folder structure and how can I set up the application so that when I make a change to a color variable then my .css files get updated.
Update
As suggested I placed all the .less files in the same directory as my css.
However what should I do next? I tried to view the URL
http://127.255.0.0:82/Content/Stylesheets/bootstrap.less
in my browser but got the following message:
(
Expected '}' but found '~' on line 522 in file 'mixins.less':
[521]: .spanX (#index) when (#index > 0) {
[522]: (~".span#{index}") { .span(#index); }
------^
[523]: .spanX(#index - 1);
I currently compile the less files on build with nodejs.
You need to install node.js.
Once installed, in command prompt type: "npm install less -g" this installs the latest less globally (-g on the end for global).
In visual studio, go to Build Events in the websites properties page and put in a "pre-build event command line" like the following:
lessc $(SolutionDir)path-to-main-less-file.less > $(SolutionDir)path-to-where-css-is-output.css -x
EDIT: Bootstrap now uses Recess and npm command has changed as seen here.
Go easy on me, It's my first post! :)
This is a known issue in Dotless:
https://github.com/dotless/dotless/issues/155
Basically the Bootstrap source code is using LESS features that are not yet supported in the version of Dotless that you use. Apparently support has been added in the latest source though, so you should be able to resolve this by compiling Dotless from the latest source.
It is not enough to download and reference dotless.Core.dll, because the binary files aren't up-to-date enough, i.e. they do not contain the latest features that you need for Bootstrap. Only the source files contain the latest changes, so you have to produce the dotless.Core.dll by compiling the latest source with Visual Studio. Of course these features will be included in the .dll download when they next decide to update it.
Dotless produces the result file bootstrap.css "on the fly". You never see that file on the disk, as it is produced by compiling the .less files when they are requested via HTTP. The CSS that is produced is only cached in memory. However you could always request the .less file in your browser and save what you see to a .css file. That would work but there isn't much point in doing it if your Dotless installation is working properly.
However, if all you want is a bootstrap.css file with your customized values, you can also use this online tool on the Bootstrap website. It will let you change the variable values and download the resulting CSS.
Have you tried Mindscap Web Workbench?
They have an article on how to set it up for use with Twitter Bootstrap.
You can use Combres to with my dotless plugin here. All you need to do is reference bootstrap.less and all the imports will work out of the box with clean Bootstrap less files. Combres will build and cache the bootstrap file and even compress it with other non-Bootstrap css files. This is the ideal setup.
http://pknopf.com/blog/using-less-correctly-with-combres
I want to use some libs in my application, like https://github.com/Panmind/erlang-ruby-marshal. That repo holds an src dir, but has no .app file (because it's not an application), so I can't use get-deps.
I tried another approach, adding a libs dir in sub_dirs and added the repo as a git submodule, but rebar won't compile any of its files. I guess that rebar only compiles otp applications, but not just .erl files that aren't tied to an application.
How do you manage those kind of dependencies? I would like to avoid copying the files to my app dir, because I don't think they belong there, and I kind of like the git submodule approach, that allows me to keep track of the lib version I am using.
Recent rebar supports raw option for dependencies. When this option is specific, rebar does not require the dependency to have a standard Erlang/OTP layout which assumes the presence of either "src/dependency_name.app.src" or "ebin/dependency_name.app" files (see more details here).
For example:
{deps, [
{erlang_ruby_marshal, "",
{git, "https://github.com/Panmind/erlang-ruby-marshal", {branch, master}},
[raw]}
]}.
Note that rebar will now be able to fetch it, but it still won't compile it. As other commenters pointed out, there's no reason why this dependency should not have an .app file. I would fork the repository and add the .app file to it.
This article goes through the bigger process of creating applications and releases with rebar.
More specifically, I think this option in rebar.config might be what you're looking for. The only way I've found so far is to have one entry for each application:
{sub_dirs, ["libs/app1",
"libs/app2",
...]}.
This requires a bit more manual work. Unfortunately rebar is very structured around the concept of one app only, and would need some better support for caring for a repository with a bunch of equally worth applications instead of a single application.
If you are using Linux, you can add the required modules as hard links, into the src directory of your application.
This is far from optimal but I have yet to find a better way to do this.
Ask the Agner guys to add it to their package management system. In the process they will create a fork and convert to make the project rebar compatible. Also, the original maintainer will quite possibly integrate the changes.