30

I have a JavaScript based library I'd like to include in a Meteor JS application. The library source code is hosted in a Git repository and I'd like to include the repo as a submodule in my own source code repo for my Meteor app. However, I don't need a majority of the files included processed by Meteor, only a few select ones. Indeed Meteor barfs with "Error: Couldn't parse .. um .. some HTML file, on some line. sorry" when it sees many of the files in the submodule.

Is there a way to selectively whitelist or blacklist files for inclusion into the Meteor app inside the project directory? Apart from creating a Smart Package, are there ways in which I could include external resources such as Git submodules inside my Meteor app project directory.

Update: as explained in the related question of "How to create a package", if you create a Smart Package into a local Git checkout of Meteor itself, you get the hot-reload behaviour for the code in the package.

Community
  • 1
  • 1
mz2
  • 4,672
  • 1
  • 27
  • 47

5 Answers5

34

In addition to the /public directory that jonathan mentions, Meteor also ignores any directories that begin with a "." - so you could create a .submodules directory and put the files in there and Meteor won't load them.

This is probably preferable to having them in /public since, well, they're not public.

apb
  • 3,270
  • 3
  • 29
  • 23
  • Damn, yeah I forgot about those. That's the answer then I guess. – jonathanKingston May 03 '12 at 02:21
  • How would you go about loading them? +1 for the interesting info though : ) – Alexander Varwijk May 03 '12 at 09:29
  • Ah, brilliant! Thanks a lot for that. A follow-up question to this: I tried symlinking from .submodules those files I actually want Meteor to process, then changing the source file, but it looks like Meteor is not picking up the changes to symlinked files. – mz2 May 03 '12 at 17:19
  • Yeah symlinked code seems to get cached restarting the server on code change works though. Not sure if that is a bug or just an inherent issue with symlinks or perhaps Meteor can't access those files directly. – jonathanKingston May 03 '12 at 19:24
  • I just noticed in the answer to this question http://stackoverflow.com/questions/10114526/how-to-build-a-meteor-package that you get the hot-reload behaviour with smart packages when they've been created for a local Meteor checkout. Edited my question to point this out. – mz2 May 06 '12 at 06:38
19

Update: in the upcoming release of Meteor (0.6.5) there is a private directory in which you can put files that are inaccessible to the client and not automatically loaded on the server. The Assets global object and API allows you to read these files.

Andrew Mao
  • 35,740
  • 23
  • 143
  • 224
2

There is also now support for a .meteorignore file (Meteor v1.5.2.1). 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.

Lucbug
  • 475
  • 6
  • 16
0

No, the only way to do this is write an import script.

There is a /public dir you can use to have all the files in if you didn't know of that.

Personally however I wouldn't consider this an issue as surely you don't just want to import files in based on a certain path, if they changed their code to add a new required file yours would break too. That is not something I would want to find out on deploy, rather plan for each change of version of the dependency.

jonathanKingston
  • 1,418
  • 10
  • 16
  • Yeah, I know what you mean, it's more of a shortcut in a case where the stuff I use as a submodule in the context of Meteor is changing actively enough that it's a pain to keep packaging it as a Smart Package every time I change it. Basically, I'd like to get the benefits of the autodeploying magic also for this code that is not strictly tied to the Meteor app but also used elsewhere. – mz2 May 03 '12 at 17:21
0

It sounds a bit odd, but in Meteor 1.3 there is the..

/imports

..directory, that is not automatically included by meteor.

It is 'meant'/suggested by the name, to be for modules that you 'import' from your other code. But you can just as well use it for your own app code, and I think it is a better name for app code than /private, but that is my personal opinion :-)

Michiel Dral
  • 3,932
  • 1
  • 19
  • 21