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.
Related
I have been working through the Meteor Tutorial and have created my first project in my workspace.
I do have the list of files as described on the first "Creating an app" page; however, if I reference the Application structure | Meteor Guide, they are showing more than just the two client and server folders.
Are the folders described in the Application Structure guide, a layout scheme that I need to create, or should the meteor create simple-todos command have build this out for the reader?
You can have more than client and server folders in a Meteor application. The simple-todos application just uses these two folders, but for more complicated apps your needs can call for a more complex structure.
Before Meteor 1.3 the file loading of Meteor was different. Then you had several other folders that had special functionality, like lib, private, public. From 1.3 this has changed, and now we only have three folders: imports, client and server.
Anything placed inside the imports folder is not loaded by Meteor. Here you put your application code, and then you import it from anywhere outside this folder. This ensures that Meteor only bundles the code that you intentionally state that you will be using. This way you can write code that is not bundled in the app before it is tested and ready for use.
This is explained in the guide:
To fully use the module system and ensure that our code only runs when
we ask it to, we recommend that all of your application code should be
placed inside the imports/ directory. This means that the Meteor build
system will only bundle and include that file if it is referenced from
another file using an import.
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.
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.
can I configure jwrapper's xml so that a directory/file is included and put into the shared folder, not into the app folder ?
mydir/myfolder/foo
I would like to access it via
JWSystem.getAllAppVersionsSharedFolder()
Thank you
Peter
You can't have JWrapper copy files into the shared folder as it doesn't really fit in with how JWrapper works conceptually.
When you release a new version of your app the updated files will all be contained within the app folder (JWSystem.getAppFolder). From there you can save files that you want to remain consistent across versions to the all app versions shared folder (JWSystem.getAllAppVersionsSharedFolder).
However, managing the consistency of those files across versions and how they are updated is something that your app has to do since it will require context about what the files are and how they should be modified, updated etc.
If its just a case of overwriting files with the latest version then there's no real need to put them in the shared folder, you can just access the files bundled with your latest app version via the JWSystem.getAppFolder call.
background:Me and my coworkers are working on asp.net mvc project ... we have a computer that works as a server which is where the project will be stored on... each of us has a copy of the project and we got tortoise cvs set up.
questions:
when you want to commit something, what files exactly do you commit?.. asp.net reports many dll files, csproj files, cs and sln files that appear to be different from the server's.
Maybe my question is not the right one I should ask so I would appreciate some insight on whats the best approach for working in groups.
The basic csproj file should be committed whenever you add or remove things from the project, to ensure that the project has all the correct files. The solution (sln) is a good one to commit, for the same reason, although I've also seen it done without. You'd also want to commit any cs files, naturally, as they're the main focus of things.
DLL files should only be committed if they're outside references--internal dlls to your project can be ignored, as they'll be built by each computer in turn. You also want to avoid .user files as unnecessary. Ignore the 'bin' and 'obj' folders for each directory, when it comes to commits as well.
You really shouldn't check in anything that the project can generate itself. So no need to check in your bin or obj folders or anything like that, you also want to ignore any user preferences files.
This includes dlls, unless they are third party dlls, then you want to check them in to ensure everyone is working against the same version and this way you don't have to keep changing reference paths.
I don't work in asp.net, so I will respond generically.
We have a subversion code repository for our version system, cvs works well too. Developers retrieve all updated code from the repository, do work, make sure it's working correctly, do another get, re-compile, test, and then commit source code changes to the repository. On a regular basis you can have a tool or manually build the application from the repository, and deploy to a testing server. No compiled code should be placed in the repository.
-Jay
We use the following project structure in SVN (but this applies to CVS as well).
+ tags
+ branches
> trunk
+ build (build scripts)
+ lib (external libraries)
> src (source code)
>> Organization.App (solution name)
>> Organization.App.Core (code library)
+ Config
> Domain
> Model
> Persistence
> Queries
> Services
> Persistence
> Services
>> Organization.App.Web (mvc web app)
> Assets
+ Images
+ Scripts
+ Stylesheets
+ Controllers
+ Views
+ ViewModels
We put all our 3rd party dependencies into the lib folder. Including MVC, which can be bin deployed. See this article by Phil Haack. So when a new developer comes online all they have to do it check out the trunk, and they should have everything they need to get going. Using a CI server is a cinch because all of the projects dependencies are encapsulated by the lib folder and all of the visual studio projects make reference to those dll's in that lib folder.
Does that make sense?
Never mind the core folder and the web folder. That's just how we structure our projects within the solution. But that's a whole other conversation. :)
We keep everything except the BIN/OBJ folders in SVN. We have all third party Libraries in a seperate folder that they are referenced from.
Kindness,
Dan
If you are using a database change management tool, such as Tarantino, then you will also want to check in SQL change scripts and/or populate scripts. We have a folder in our 'Core' solution where we keep these, ie 'Core/Database/Updates'. We use SQL Compare to find changes in our database then we check in those SQL change scripts so that other developers can just run them locally. We have a nant task setup to call on Tarantino to sync up the other build environments (Dev, QA) and run any new change scripts.