I am working on a new Meteor app that I want to structure as a set of packages.
For each package, package.js is used to specify what files to include for client and server. This is standard usage.
My question: I want to divide a package into features, and I'd like to describe each feature with a file on the same lines as what package.js does for packages. The main function of the feature file is to list the files of that feature that are required on client and server; concretely the feature file will contain api.use() calls that logically are included in the parent package.js file. In other words, I'm looking for an 'include' functionality for package.js.
Is such a thing possible, and how?
I solved this myself by generating the api.addFiles calls in the package.js. To do that I tweaked the npm meteor-package-paths module, in particular the js.coffee module to add the additional 'feature' layer of directories.
Related
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.
I want to build a meteor package to wrap an existing javascript library. I would like to include the library as a git submodule. I only need 2 files from the submodule. If I only include these two in package.js will the rest of the files be ignored by meteor and not built into the package?
The only files that will end up in your package are those that will be explicitly added with api.addFiles routine (look here).
BTW, If you're planning to wrap an existing JavaScript library then you should probably start by getting familiar with autopublish project. For more details watch this video.
We are using trackjs.com code to help us detect javascript errors. We want the trackjs code to report all errors in any javascript code. This requires that the trackjs code be loaded first.
I know it goes against the general meteor loading order, however we don't want any javascript issues hidden, no matter where the errors are.
We tried including the trackjs.com code included in the compatibility folder and hardcoded in a <head> block. Both of these approaches resulted in the code being loaded last.
Suggestions?
Taken from official documentation:
Files in subdirectories are loaded before files in parent directories, so that files in the deepest subdirectory are loaded first, and files in the root directory are loaded last.
Within a directory, files are loaded in alphabetical order by filename.
After sorting as described above, all files under directories named lib are moved before everything else (preserving their order).
Finally, all files that match main.* are moved after everything else (preserving their order).
So you should be placing them in the lib directory. If you place it in server/lib it is going to be available to the server, or in client/lib the client only. But if you place it in a common lib folder, then it is going to be available to both the client and the server.
That being said, it is usually a better idea to place such code into its own package. Packages have better loading order management as described in the relevant section of the docs.
Finally, you might also want to look at http://observatoryjs.com/ which targets to achieve a similar solution as trackjs and it has native meteor packages you can search and add from http://atmosphere.meteor.com
UPDATE:
These solutions place trackjs after meteor's native code and before yours and any other 3rd party's.
To be able to truly inject trackjs before everything else, there may be a few ways:
https://github.com/arunoda/meteor-fast-render/blob/master/lib/server/inject.js#L52 is how fast-render package alters the contents of head to inject arbitrary scripts. You can inject trackjs at the very beginning using this technique.
You can directly hack https://github.com/meteor/meteor/blob/devel/packages/webapp/webapp_server.js how meteor serves the app. This would again be client side only and prone to meteor update conflicts.
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.
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.