Problem with .meteorignore

help
1

I tried every possible combination of path, *, names, absolute, relative and .meteorignore does NOT work.
My .meteorignore is in public/assets/Images but every time a file changes in there Meteor rebuilds the project ignoring the .meteorignore. Here are my test contents:

/home/felix/base-app/public/assets/Images/*
public/assets/*
*
Images

Nothing works…

2

I’ve got mine in the project root if that makes a difference

3

Seems to do something when there is simply , ignoring the entire project. Obviously that make the build process fail. However, with any combination of /Images /Images/ Images or any other still does NOT ignore the public/Images folder…everytime a new file is added in the Images folder, project rebuilds.

4

Okay I’ve tested it on my project and it does seem that .meteorignore doesn’t work for stuff in public

Probably because of the reasons specified in this thread:

Specifically this comment:

Just to add, do you mean your application allows files to be uploaded into the /public directory? If so, this approach is not recommended as your /public directory is considered to be part of your application bundle. When you redeploy, you’ll be blowing away that directory and replacing it with the contents of your new app bundle (which means application uploaded files will be removed). I would highly recommend finding another way to store uploaded files, either by storing them in a directory outside of your application, using a database, using a cloud hosted file storage solution (e.g. S3), etc.

If you could ignore public it would lead to very counter-intuitive results, as these are copied into the app bundle in .meteor/local/build/programs/web.browser/app/ (and legacy) and served from there.
If ignored, those files wouldn’t make it into the bundle and you’d wonder why you can’t load the images in question

2 Likes
5

Final solution was to setup nginx on the same server with a default reverse proxy to port 3000 for the regular Meteor app and a different root location for /images. If anyone is interested in my nginx configuration let me know. Thanks to all for the much appreciated help, great community.

1 Like
6

I’m a little confused by this thread and was wondering if you could set my mind at rest :slight_smile:?

Why would you want to use nginx to reverse proxy in development? I can understand it in production, but given that public is intended for static Meteor assets, and you would normally want to restart on change (to see the effects during development), why disable that functionality?

1 Like
7

This app is for internal use and it is not exposed to internet, at least not directly. File uploads to the /public directory was causing problems obviously. It was surprisingly simple to add nginx to the project and solved the problem.

8

Exposure to the Internet was not my point.

A deployed Meteor app (internally or not) does not run under control of the meteor command. It’s a standard NodeJS process and has no file watcher, so can never restart because of a file change.

If you are running this app with the meteor command, consider packaging and deploying it.

9

Very easily explained. Something that people here usually, in their zeal to cloudify all the things overlook:

You need to retain control over all the files and only store them in a location you have absolute control over.

In that case you want something to be uploaded to a folder that is then accessible to the client. Which is the /public folder by default.

So you develop a form which, say, lets you upload pictures alongside some information. However, as soon as the picture is uploaded in development the whole application restarts and you can forget about filling out the form to test the whole process.

That’s why this “let’s treat the /public folder special but for god’s sake don’t mention that anywhere!” so annoying.

Hence the necessity for the nginx reverse proxy in development. Because for some asinine reason you guys think that we can’t be trusted with this.

Instead of, say, throwing out a warning during the actual build process. Something like:

Your .meteorignore file references a non-empty folder in the /public directory. If you meant to ignore those files you can dismiss this warning