I know the Meteor file structure is a bit ambiguous, but at this point some conventions has formed and I was wondering where people usually put the code that runs on both server and client. I would like to keep it in a separate folder/file to make the project folder more manageable. I have a client folder for client-side code, a server folder for server-side, and a public folder for public files. But I'm unsure what the conventions say about the shared code that runs on both the client and the server, like declaring collections, etc.
Thanks!
From the docs,
All JavaScript files outside special directories are loaded on both the client and the server. That's the place for model definitions and other functions. Meteor provides the variables Meteor.isClient and Meteor.isServer so that your code can alter its behavior depending on whether it's running on the client or the server.
Also from the section on File Load Order,
There are several load ordering rules. They are applied sequentially to all applicable files in the application, in the priority given below:
HTML template files are always loaded before everything else
Files beginning with main. are loaded last
Files inside any lib/ directory are loaded next
Files with deeper paths are loaded next
Files are then loaded in alphabetical order of the entire path
This suggests that the best practice would be to place the files in the lib/ directory.
Related
I need to bundle some data files (geoip data) with my meteor application. Simply putting the data files in my application directory doesn't appear to do anything - they're not copied to anywhere in .meteor/local/build when I run meteor.
How can I make meteor copy these files when it builds my application?
So, files are loaded on different environment is a specific order. Have a look here for details on what's loaded where and when.
https://guide.meteor.com/structure.html#load-order
Then you can decide where best to place the file depending on the use case.
How can I access less files on the server in meteor.
I would like to dynamically generate css from them but when I do fs.readdirSync('../client') I only see the compiled css.
If you want to use a file as a raw data on the server side, you should put it in the /private folder and use assets. Files placed in /client folder are treated as part of the application and compiled by Meteor, source is no longer available after bundling.
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.
Let's say I have a folder 'content' that (for some reason) may or may not be present in the source folder tree for a Web Deploy sync operation.
With what skip setting(s) can I have Web Deploy sync the contents of this folder (regardless of whether it exists; I can use another skip setting to control which files are synced) without also deleting the folder in the snyc target when it doesn't exist in the sync source?
[Note – the line breaks in the example commands are purely cosmetic.]
With this command, Web Deploy will attempt to delete the 'content' folder in the sync target (and fail if there are files in it):
msdeploy.exe
-verb:sync
-source:dirPath=%source%
-dest:dirPath=%target%
-skip:skipaction=Delete,objectname=filePath,absolutepath=\\content
With this command, (it appears that) Web deploy will skip deleting the 'content' folder in the sync target but it will also fail to sync any files within that folder (which is eminently reasonable actually):
msdeploy.exe
-verb:sync
-source:dirPath=%source%
-dest:dirPath=%target%
-skip:skipaction=Delete,objectname=dirPath,absolutepath=\\content
It's perfectly acceptable if there is in-fact no way to do this! (But I'd like some details or references about why that would be.)
Some possible solutions:
Have a look at the -enableRule:DoNotDeleteRule switch (see rule descriptions).
You may need to include both of those skip params, per this blog post:
...delete rules on a child are only processed if the parent is not
being deleted. So if you skip a file but it’s containing directory
doesn’t exist on the source, the directory (and thus the file) will be
deleted anyway.
Also, remember the absolutePath param takes regex so some chars (like .) should be escaped.
This doesn't seem possible. If a skip delete rule prevents a folder from being deleted, then none of the child files in that folder will be deleted either, and thus the child files won't be synced (completely).
Thinking about this more, especially in light of jkoreska's answer, I think the solution I adopted isn't terrible. Basically the problem is that the source and target root folders may contain some subset of a set of folders, say for example the full set is bin, content, and templates.
The reason why I want to sync the contents of a folder that might not exist in the source (or target), is that I'd like to use the same Web Deploy command(s) for any number of instances of sources and targets.
My solution was to simply guarantee that the source instances always contained the full set of folders, and thus all of the targets would too – after at least one execution of the Web Deploy command(s).
I noticed that Eclipse (Flex Builder) generates hundreds of metadata files. Should I check them into my source control? They seem necessary, because if I delete them Flex Builder just opens up an empty workbench...
Some of these files plainly do not belong in source control (like .history files and some cache files). If I delete them my project opens up again without a hitch. But the list is long and there seem to be no clear separation between folders that contain files that belong in source control and those that do not.
I can't just shove them all into svn, even if I were to ignore the inefficiency, because Eclipse generates new ones constantly, with different names, which in turn also seem to be crucial for the project to load.
Can someone please enlighten me?
Don't check in the hundreds of metadata files. If you want to be able to check out the project in a way that it can just be imported, then check in:
.actionScriptProperties
.project
.flexProperties
And "html-template" and "libs". As Christian says, any resources you depend on. I usually keep those as separate Flex Library projects though.
I generally put all of my source code under src, and I check in src and all of its descendents. If my project relies on any external dependencies (e.g., the Cairngorm SWC, as3corelib, etc.), Flash/graphical assets, stylesheets, or resource files, I check those in, too. But I don't check in any generated (bin-*), intermediate or IDE-specific stuff, because having that stuff in source control doesn't seem to provide much practical benefit, and in my experience has only caused me headaches; in general, I check in the most minimal set of whatever I'd need -- given a clean FlexBuilder installation (or none at all -- for example, if I were compiling instead with mxmlc or compc) and an empty project -- to build the project successfully.
Most of the eclipse project files, like .project, .properties, everything in .settings, can go into your source control. As long as the files don't have user-dependent settings like file paths or local urls, you should be fine.
One method we use is creating local property files that don't get used in SCM, but are included in the ones that do. I.E an ant build file including a local.properties file which has local metadata.
What if the .actionScriptProperties, .project, or .flexProperties have user-dependent stuff in them? Typically this will be url or path information. What's the best practice way of externalizing this? I tried creating path variables, but this only works obviously for paths. Not for things like hostname, etc.