I have a library that I'm developing and I'm publishing it to bower. Right now I'm ignoring everything except genie.js (the library) and genie.min.js. Is there value in having the README.md or the travis build file or the demo files or anything else? It seems to me that the reason someone adds your component to their project is so they can use it in their product and they don't want their file system polluted, am I wrong?
You're right, just the minimum. I would go a step further and drop the minified file, which is the best practise in Bower, as users are most likely using a build system and having an additional minified file is just wasting space.
You can easily ignore everything but one file by using globbing in the "ignore" property in bower.json like this:
"ignore": ["./!(genie.js)"]
Related
I ran this command to create a ReactJS app
npx create-react-app learningapp
This created several folders now, I dont know which of them are important. I mean I dont know their purpose.
Can anyone explain their purpose in short?
node_modules -- very important, as this will contain all the npm packages and their entire list of dependencies installed.
public -- very important, contains the static files served by your web server.
Index.html -- the index.html file where your react app will inject elements into. I believe this is the only "essential" file.
The other files in this folder will contain logos and manifests if you'd like your webpage to be able to be installed as a mobile app seamlessly. The manifest.json file holds the information about what the app icon and such will look like.
Favicon is the tiny logo you see in your tab title
robots.txt will have the instructions for bots visiting your website. Read about it here if you'd like (https://www.cloudflare.com/learning/bots/what-is-robots.txt/)
src -- very important, will contain your source code. If you want your app to do anything at all, it wouldn't be very wise to delete this folder. If you want to rename this to something else, you can, but you'd have to mess with the webpack configurations. So, not worth the little extra effort. However, you may alter the folder contents.
Unless you want performance monitoring and are writing tests for your app, you can safely delete the test file and the report webvitals stuff. You can make your test files somewhere else too, it doesn't matter if it's here. Just make sure you configure your testing library so that it looks for the correct files.
The rest of the files in this folder can be modified all you like, but try not to touch index.js unless you want to go mess with the webpack configs to change the entry point. Webpack looks for index.js as an entry point to build its dependency tree during compilation.
.gitignore -- this is the files/folders you can tell git to ignore when tracking your folder. A usual candidate for this file is the node_modules folder.
package.json/package.json -- very important, don't directly mess with these unless you know what you're doing. This contains the info about npm packages which your require to run your project properly. A situation where you will need to mess with package.json is when you want to add some custom npm scripts, which is often quite useful.
README.md -- just your readme file which is used to display info about the project on your github repo for example. You can delete it, but just put something on there containing basic info about the repo/ what it does.
How do I actually use the frontend files that Composer installs? Specifically JavaScript. I've been able to use a PHP file previously, but JavaScript files are breaking my brain...
I've installed Composer and used it to install a package (Handlebars, specifically). Everything looks like it should. I've got a handlebars folder in my vendor folder and it created a "components" folder with some JavaScript files in it, so I know things are there. I've tried just doing this:
<script type="text/text/javascript"
src="/components/handlebars/handlebars.js"></script>`
But that doesn't seem like what I should be doing and doesn't seem to work anyway. I see there's some require files in there as well, but I've tried referencing them with no luck.
I would hope that just including require __DIR__ . '/vendor/autoload.php'; would do it, but that seems to just bring in the backend stuff.
It seems that Bower may be better suited for frontend stuff like this, but I'm already using Composer for another part of the project, so it would be nice to not have to use two different package managers in one project.
If you are using any kind of front-end buildchain, you can simply point the build-chain to the location of your JS package in vendor, and only put the "built" assets in your web accessible directory (called public in many projects).
If you are not, you'll have to simply either copy or symlink the JS (and/or CSS) dependencies from its vendor path to one that's web accessible. You could automate the process by having a script section in your composer.json. Something along the lines of this (made up, adjust to your actual needs):
"scripts": {
"copyHandlebars": [
"cp vendor/handlebars/dist/css/handlebars.css public/assets/handlebars.css",
"cp vendor/handlebars/dist/js/handlebars.js public/assets/handlebars.js"
],
"post-update-cmd": [
"#copyHandlebars"
],
"post-install-cmd": [
"#copyHandlebars"
]
}
Composer is mainly a PHP dependency manager, and while you can use it to install some frontend packages, usually you'll be better served by a manager build specifically for frontend. As soon as your project reaches a minimum level of complexity, separating the needs of front and back is usually good, since front will have more specific and appropriate tools both to manage dependencies and to build assets.
I am creating a basic JS framework which I will be uploading to Github and hope to create a bower package so that I can install it in my other projects using Bower. I've never done this before but I could probably work that bit out.
The confusion comes with other dependencies which my Framework relies on. For example I want to specify Fastclick.js as a dependency and call it from within my framework like this.
window.addEventListener('load', function() {
FastClick.attach(document.body);
}, false);
So my question is how am I supposed to do this? I assume I don't include the Fastclick library in my compiled "/dist" folder and that I can specify it in my Bower file so that when somebody installs my framework they will get the correct version of Fastclick? If that's the case then how do I make sure they load the library before my library? I don't have control over their HTML or the order in which they load scripts.
I could just copy and past the Fastclick code into my library, that is one option of course but I feel there must be a better way to do this. My brain is telling me that to do it properly would require some kind of JS module loading system though.
As you can tell. I don't really know what I'm talking about so apologies if the question is quite vague. Any help would be greatly appreciated though.
Do a
bower install --save <library-name> // in your case Fastclick.
This will create a bower.json file, or update it with the library. It should also be saved now in bower_components/.
Now go to bower_components/<library-name> and see which file you want to include into your project. For example, from the bower.json of FastClick, it seems like you need to include lib/fastclick.js for the functionality.
So to use the library, in your project's index.html, you'll need to add a script tag something on the lines of:
<script src="bower_components/FastClick/lib/fastclick.js"></src>
Now you're done!
Anyone who clones your git repo simply has to do a bower install, and everything should work out of the box.
You don't need to checkin the bower_components folder, but only the bower.json file, which can be used to install all the dependencies.
Hope this helps!
In the end I just included the whole Fastclick library in the code I was bundling up. It was the only way to ensure that it got loaded first in the final app. I could have just included it in the bower file and the final app would have needed to include it in their template in the right order, but this way seemed safer.
I am continously encountering the issue, where I need / want to include a specific file from a bower package to my app, and find no easy way to do it. This is not limited to minified versions.
Example: Moment.js comes with about four different files one can choose to include. Those are moment.js, moment.min.js, moment-with-langs.js, moment-with-langs.min.js. The bower.json and the hidden .bower.json files inside the package specify which file should be included during the build in the "main" array (here's an example with sass-bootstrap bower package):
"main": ["./dist/js/bootstrap.js", "./dist/css/bootstrap.css", "./dist/fonts/*"]
But there is no such thing in the apps bower.json file to specify for dependencies. One can only specify the dependency.
There is some discussion on the case: I found two topics on bower's github, namely https://github.com/bower/bower/issues/368 and https://github.com/bower/bower/issues/369 and also here How to configure Grunt to replace Bower dependencies by its minified versions but the issue is not limited to the minified versions.
All the topics end in the same way, stating that bower, as a package manager, should not take care of the custom build process that an app requires. But that leaves the developer with the problem of having to go about bower with the majority of the repos OR minifying the packages on his/her own. There are many who disagree on both.
The way I went about the problem with moment.js is I created a vendor folder and manually added the file that I needed and then added a Grunt task to do it automatically. But it just would be so much easier if there was a standard way of providing users the option to include e.g. all recommeded (default) files, the minified versions or just allow to choose specific files from the app's bower.json dependency list.
Perhaps I am not using it right, or maybe it's not a popular problem. I don't know if it's some feature that should be added to bower, but maybe other devs have experience dealing with the case?
If you use browserify it has debowerify transformation that just grabs the first file from the main array. To include a particular extra file call the require function with appropriate path.
Is there anyway to easily compile CoffeeScript on save? I'm using TextMate or Sublime Text 2.
Coffeescript has a 'watch' feature. You could set up, as a semi-permanent process:
coffee –wc -o media/js/ src/coffee/*.coffee
And for every file with an extension ".coffee", the corresponding compiled ".js" file will be put into the target directory every time you save.
That said, I use a makefile and a fabfile, because my HTML is HAML, my CSS is LessCSS, and my development directory is not my test path, so I needed something smart enough to "build and deploy."
If your machine supports inotify, you could use inotifywait to watch your entire work path, and call Make as needed. But at that point, you're into hard-core geekery.
You can also accomplish this without the command line:
Add a build process to Sublime Text.
Make sure that Save All on Build is selected in the Tools menu.
Use ⌘B instead of ⌘S when saving.
So instead of compiling on save, you're saving on compile.
The most straightforward solution with Sublime, is to install the Sublime package called Better Coffeescript (preferences --> package control --> install package...), and then make sure that its configuration includes "compileOnSave": true (preferences --> package settings --> Better Coffeescript...). Then restart Sublime.
For Sublime, anything else is not enough or too much extra components. Just came here after upgrading to Sublime 3, and it works like charm for Sublime 3 (as it did for Sublime 2, I just forgot about it at first).
Well coffee --watch has 2 major flaws:
New files created after command has been issued aren't being watched
Requires manual initiation so there can be a chance you forget to do it, which doesn't sound more brilliant than forget to compile before you git commit it
The solution I came up with is a rather simple Bash script that takes coffee --watch a few steps further which will allow your working directory tree to be watched ever since system login, and automatically get compiled into JavaScript on each file save/change
or new file creation:
http://blog.gantrithor.com/post/11609373640/carefree-coffeescript-auto-compiler
There may be more elegant way to do this, but this implementation works great =)
If you also want bundling, buildr offers watching and bundling too: https://github.com/balupton/buildr.npm
The (Java|Coffee)Script and (CSS|Less) (Builder|Bundler|Packer|Minifier|Merger|Checker)
gem install stasis
stasis -d
The best solution I have found compared with all other static compilation tools like StaticMatic, Middleman, etc.
Very flexible and configurable and does not rely on any preset folder structure. Just add controller.rb and write some Ruby. Lots of helpers for doing clever things before/after compilation.
https://github.com/winton/stasis
I like codekit :) Simple and effective way to compile coffeescript, sass, less, haml, and more, with lots of niceties. http://incident57.com/codekit/