Tl;dr : Is there an equivalent in meteor to .gitignore?
Yes, I am aware of using a leading '.' in the directory name to get meteor to exclude it. But using leading dot is not a solution in this case. Read below to understand.
Longer:
I would like to use Bower.io to install various browser plugins.
Ideally, I run bower in the client subdirectory. Bower does its thing creating the bower_components directory and pulls down the plugin (pick a random jquery plugin for example).
Many plugins include example html, demo css files, etc. to show how to use the plugin.
Unfortunately, Meteor wants to include all that stuff in the application. Which unsurprisingly causes problems.
My current solution is to have bower.io run in the project's parent directory. This is not ideal as I have to copy js/css files over from the bower directory to the meteor client directory. (yes, I could use soft links but then the files would be missing when pushing to production).
With only a few client plugins / css packages this is becoming quite annoying.
NOTE: Renaming files/directories retrieved by bower.io to have a leading '.' or using bower in a dotted subdirectory helps only marginally. I would then have to manually include the files needed.
Is this possibly a duplicate of How to exclude directories/files from Meteor's bundler?
If you want to define the way you name your files, you could try including a certain regex to match in the meteor bundler. Otherwise, maybe it's something that needs to be implemented on a framework level.
I also found this tutorial by Tri on integrating meteor and bower: http://tridnguyen.com/articles/meteor-and-bower/. Tri defines a new meteor package to specify the exact files required on the client.
The best solution, however, is move away from Bower as Meteor offers its own package manager at a framework level. Including the front end files that you need using Meteor packages would be the more productive solution in the long run, especially as the framework changes.
Related
I'm an old COBOL programmer that has self-taught myself web development over the last decade. I've always used asp.net for developing and when I first started out I had no clue what I was doing. There are some cases I still don't :). That brings me to my question. When I first started out I didn't know what Nuget packages were so if I wanted to use something like bootstrap I would would download the files from the bootstrap website and load them into my project in a Scripts folder. To call the files I added them into the bundling function provided by asp.net. I've since discovered Nuget Manager and keep my bootstrap versions updated through it, but I've always been afraid to remove the reference to these files from the bundling package.
Today I'm trying to upgrade bootstrap from 4.6 to 5.1, but I'm getting an error. If I go into my bundling package and comment out the reference to bootstrap my error goes away. So my question is, if I'm using Nuget to manage my packages, is it safe to remove them from the bundling package? I feel like the answer is "yes it's safe" but was hoping for confirmation and maybe an explanation on how and if Nuget and bundling work together, if at all...
Well, nuget simple in "most" cases downloads some .net .dll's and assemblies, and then often sets a reference for you. (you could do this manual, but hey its a whole lot less work).
but, when you use nuget to install those packages, some might include javaScript libries and code (such as your example).
Because the bundling expects the scripts to be say in this location:
Public Shared Sub RegisterBundles(ByVal bundles As BundleCollection)
bundles.Add(New ScriptBundle("~/bundles/WebFormsJs").Include(
"~/Scripts/WebForms/WebForms.js",
"~/Scripts/WebForms/WebUIValidation.js",
"~/Scripts/WebForms/MenuStandards.js",
etc. etc. etc.c
Then of course, when you nuget a package, then the location of the scripts VERY LIKLEY is not going to be the above location.
So, you would then remove your older scripts (and above script referances), and add in the new location of such scripts.
So, you are free to remove the existing bundling references, but you not then enjoy use of the script manager and system to "merge together" the many script files.
So, you don't have to use bundeling anyway.
However, in most cases, you WANT BOTH the SomeJava.js and SomeJava.min.js files to exist. And if you modify those files, then YOU need to regenerate the .min version. Since you not (likely) to be modifying those .js files, then you can well dump the bundling of such files. But you are free also to add them to the above bundling reference.
All bundling does is "merge" the .js files together - so that you don't have 50 or 100 different separate .js files, and thus 50 or 100 difference downloads and references in a web page to use all those many .js files.
So, it not a huge deal. If you only adding say bootstrap via nuget, then I would hunt down the location of the new .js files, and add them to the bundling. But, it not all that huge of a deal if you don't. The issue then becomes how do you add the new .js and .css files to the given web page you are working on. (and toss in use of a master page, and again more complex).
So, in theory, you could remove the existing (older .js references) and then add the css. files that nuget created. I not looked, and don't know if the .js files remain in "packages" folder, or during an install that nuget copies to some folder (such as scirpts).
Just keep in mind, do keep and have the .min versions of those .js files. if you in web.config set debug=false, then the web site flips over to using the .min versions of the .js files - they have to exist, and even without bundling they have to exist, and this "flip" occurs (you now using .min versions of js files).
This is a HUGE topic, and probably oh so far beyond that of a simple post on SO.
but, suffice to say, you can well dump use of the bundling, and remove your older .js references. (but, since you having to do that, then might as well add the newer references then at that point in time, right???).
I have a package which includes a file that gets frequently rebuilt. This causes meteor to restart each time that file is edited.
There are ways to get meteor to ignore files within the main app, eg putting inside a .directory but is there a way to do this within a package?
The catch is that I DO need the final file to be included for deployment, so it has to be named - as an asset - and included in the package addFiles.
The only solution I have so far is to host the asset external to the meteor app and load it in via http or something on each cold start, but that's a bit fragile.
As of Meteor v1.5.2.1, there is support for a .meteorignore file. It behaves the same as a .gitignore. Have you tried using it?
You can use them in any directory of your project and are fully integrated with the file watching system.
Is there some specific folder in Meteor file structure which is simply ignored by Meteor? (meteor bundle and meteor deploy etc)
Or better yet: is there a kind of .meteorignore file where we can list files for Meteor to ignore?
There's no such file as .meteorignore yet.
Currently the only reliable way to hide a file from Meteor is to make it hidden (add a dot to the beginning of name). You can hide the whole directory, which is useful if you need specific filenames for things like Grunt tasks.
For example if you create a directory called .hammerTime, then Meteor can't touch this.
Update:
As of Meteor v1.5.2.1, there is support for a .meteorignore file. It works exactly the same as a .gitignore.
As of Meteor v1.5.2.1, there is support for a .meteorignore file. It works exactly the same as a .gitignore.
You can use them in any directory of your project and are fully integrated with the file watching system.
I am using bootstrap in Meteor and found that there is a modified flat design here: http://designmodo.com/demo/flat-ui/. Among the files seems to be a modified set of Bootstrap files. Is it possible to somehow use those css and js files to override the default bootstrap files to get the Flat-UI in a meter app? Thank you!
it's quite simple:
unzip the contents of the flat-ui-master.zip from the flatui site, then follow these steps:
create these folders in your app root: /client/stylesheets
copy the contents of the .zip into /stylesheets
remove the index.html and README.md files as they might cause your app to crash, and are not needed
meteor automatically takes care of the rest.
Although manually insert files works, I'm using meteor package jss:flat-ui
meteor add jss:flat-ui
it will automatically add flat-ui and twbs:bootstrap.
Note that, it might be better to remove any bootstrap package before installing this, I've been in a project that has mizzao:bootstrap installed and the login ui not working, so I remove mizzao:bootstrap and reinstalled flat-ui to make it work.
You can use whatever css you want to, Meteor don't care.
I wouldn't add the bootstrap meteor package though, I'd just download the css files you want and place them in your project. That way you know exactly what files are used and can easily make changes.
Here's some info on how to structure your app: https://github.com/oortcloud/unofficial-meteor-faq#where-should-i-put-my-files
I created a shell script to generate a custom bootstrap Meteor package from either a precompiled distribution, or from your own clone of the Bootstrap Git repository.
You can find it here, along with usage information: https://github.com/wojas/meteor-package-bootstrap
Just unpack the ZIP file containing the files and run this command from inside the theme folder:
/path/to/meteor-package-bootstrap.sh $your_meteor_project/packages/bootstrap
I'm creating a javascript library that I want make available through Bower to my internal company. I'm using Grunt to build my library.
My issue is that grunt's convention is to use package.json to define dependencies, library versions, dependencies, etc.
Bower, on the other hand, assumes that that same information is found in a component.json file.
What's the intended use of these two? They seem to serve essentially the same purpose. Do I need to create both and cut and paste the shared information?
We've gotten a lot of these kinds of question and everyone assumes we could share a lot metadata between these formats, but the reality is that only the name and version fields are sharable and only the version field changes regularly. If you find it cumbersome having to update two fields when you release something, there are tools out there that can automate this, eg. grunt-bumpx.
package.json is intended for back-end purposes, in this case specify grunt tasks, node dependencies, etc. In the other side, bower.json is intended for front-end purposes.