Heroku node deployment doesn't respect file name changes - javascript

I changed the filename of one of my routes from authroutes to authRoutes. When I commit the changes and deploy to heroku, the build fails because it is still looking for authroutes.
2017-09-16T15:57:57.744695+00:00 app[web.1]: Error: Cannot find module './routes/authRoutes.js'
The only reference to the file is in my index.js file via:
require('./routes/authRoutes.js')(app);
I make the change in the index.js file when committing. I've tried clearing my build cache with the heroku-repo plugin as well as making changes to the file itself. If I switch the file name back as well as the reference in index.js, everything works without a hitch. I've tried manually changing the file with heroku bash but it just switches back after the build process is completed to the all lowercase version.
Thanks!

The buildpack may be doing something with the hash comparison against the repo that requires a change bigger or more significant than a single byte changing Case.
If that is so, why dont you try a drop/add of an entire file across 2 successive git push actions?
rm your router file from project
git push heroku master ( node start may fail but so what )
add back your "new" router file with the change that the repo hash failed to recognize
git push heroku master with the new version of the router
that should fool the buildpack hasher for node projects enough to FORCE thru your change.

Related

Local Meteor Package not found

I'm having trouble setting up my project to use a local meteor package instead of a "remote" one. The meteor package I'm trying to use locally is a copy of meteortesting:mocha (so I can put my own logs into it).
Here's what I've done:
Git cloned the meteortesting:mocha repo onto my machine
Copied the repo into my project root folder with cp -r [PATH]/meteor-mocha **.**
Set METEOR_PACKAGE_DIRS=./meteor-mocha
But when I run meteor add meteortesting:mocha (which is the name of my local package in ./meteor-mocha/package/package.js) it still adds the registered/online meteortesting:mocha package instead of finding my local one.
I also tried fooling around with the name of my local package (i.e. name:"meteortesting:mochalocal") to differentiate it, but when I ran meteor add meteortesting:mochalocal it gives the error "error: no such package"
Does anyone know why this may be the case? I based my set up on this article
I know I can also try to put it in ./packages, but I wasn't sure how to approach that with this repo because it's more than just a package.js folder.
UPDATE 9/12:
Here is what I've tried (which doesn't work) with adding my local package to ./packages:
You can use the ./packages folder inside your project. Copy the package folder inside this. Then you will have:
./packages/meteortesting:mocha
Or you can use another folder to your packages. Example:
/home/my_packages
Then set this:
METEOR_PACKAGE_DIRS=/home/my_packages
Then your package will be in this path:
/home/my_packages/meteortesting:mocha

Development server compile issues and page routing broken in production builds - Next.js

Hey all so I have an app that I am working on which I am creating using Next.js.
Almost every single time I make a change the server auto compiles with the new changes which are fine. However most of the time the pages just fail to render properly.
Sometimes it takes minutes to render them properly and I have to constantly restart the server manually multiple times just to get the pages to load properly. Does anyone know what could be causing this?
I don’t currently have a next.config.js file would I need to create one and add some settings to fix these problems?
And also the page routing does not work in production builds. The index.js page loads fine but none of the routes work when I click on a link they all end in a 404. Even if I type the URL in the browser.
I solved the issue months ago I am just adding the solution I used. It seems to be some sort of git bug maybe some of the files are getting cached somewhere on git or on Netllify which is corrupting it I’m not sure. The only way I managed to it working was to create a brand new git repo and then deploy it to a new site from git on Netlify.
Copy the project into a new folder in preparation for setting up a new repo and delete the git file with its history
CD into the folder which has the next app (frontend in my case) and delete the node_modules, .next, next.config.js and package-lock.json file
Make sure that all of the components in the pages folder are lower case and not camelcase
run npm install
Setup the new project for git and then deploy it to a NEW git repo. For whatever reason my existing repo fails to get the routing working despite multiple tests and duplicate projects being identical. The only difference was that the new repos I tested only had a master branch whereas my main repo also had a develop branch. And there were only a few commits whereas my main repo had over 80 commits.
Deploy to Netlify as a new site from git
As my project was in a subfolder called frontend I had to set the base directory to frontend and then run the commands next build && next export

Meteor and the /private directory

I'm using the /private directory in Meteor 1.0.3 at the moment to store and serve up pdf documents to the browser.
As an example, I have a folder structure like so:
/application-name
/private
/files
/users
/user-name
/pdf-file1.pdf
I have a template with a button click event. In this event I make a couple of calls to Meteor methods and finally a server side Iron Router go('render-pdf') method. In these Meteor methods I use fs node.js to:
(1) check if the /user-name directory exists, and if it doesn't I
create it.
(2) create the pdf-file.pdf file
Then in the server side Iron Router go('render-pdf') route, again using fs node.js to:
(3) read the created pdf-file.pdf and
(4) finally render it to the browser
The problem is in step (1), when creating the /user-name directory, Meteor server restarts. In step (2), again Meteor server restarts.
But most importantly, the first time my code runs, and the directory
does not exist (step (1)), I get an error.
I can then call the button event again, this time after the directory has been created, and the pdf is rendered fine.
The error looks like so:
Error: ENOENT, no such file or directory '/Users/myname/meteor/meteor-application/private/files/users/user-name/pdf-file.pdf' at Object.fs.openSync (fs.js:438:18) at Object.fs.readFileSync (fs.js:289:15) at [object Object].Router.route.name (meteor-application/both/routes.js:225:17) at boundNext (packages/iron:middleware-stack/lib/middleware_stack.js:251:1) at runWithEnvironment (packages/meteor/dynamics_nodejs.js:108:1) at packages/meteor/dynamics_nodejs.js:121:1 at [object Object].urlencodedParser (/Users/myname/.meteor/packages/iron_router/.1.0.7.15dqor4++os+web.browser+web.cordova/npm/node_modules/body-parser/lib/types/urlencoded.js:72:36) at packages/iron:router/lib/router.js:277:1 at [object Object]._.extend.withValue (packages/meteor/dynamics_nodejs.js:56:1) at [object Object].hookWithOptions (packages/iron:router/lib/router.js:276:1)
It's probably that when I get to the point step (4) of trying to render the file, it either doesn't exist yet or the application is restarting. The next time I try the application has already restarted and files exist.
I was under the impression that the /private directory provides a
place to handle files that do not affect the execution of the
application? To me this means, at runtime I can add whatever I want without the application restarting.
Little history
At first I used the /server directory with a ./folder-name subdirectory. This worked as when I added folder and files the application didn't restart. The downside is when I deployed Meteor using the great Meteor-up package (mup), the deployment bundle ignored these files unless I added a *.js file somewhere inside. And further, if I created the 'hidden' folder structure on my EC2 instance, the deployment would remove the directory.
So using /private folder solved this issue, or so I thought. The folder structure and 'assets' deployed. But the downside to this approach is when I add 'assets' to it, it seems to restart -- even though I though this wasn't something that was suppose to happen.
Question
How can I add 'assets' (in the form of directories and files) under the /private directory without the Meteor application restarting? If this can't be done, how can I add 'assets' anywhere only server side without the application restarting?
Please note
When I deploy to production, I'd like some of the folder structure to stay in place, for example:
/private/files/users
should say there, while the
/user-name
directory can be dynamic. I only mention this because I've read if you do a /.directory-name, Meteor ignores the folder and its contents. But this includes deployments as well.
What I really need
A server side only folder that gets included in the deployment bundle, and when I add 'stuff' to it at runtime, doesn't restart my application...
Either a way to include /.hidden-folder in my mup deployment
bundle or have the /private folder not restart every time I add
stuff to it at runtime.
In order to keep from:
(1) overwriting/removing the directory structure every time I deployed and,
(2) restarting the Meteor application every time I created a directory or file.
I decided in my case it just made sense to use a directory structure outside of the Meteor project instead of inside as before.
Something like Dropbox/users/user-name, or anything really.
I now believe that the /private and /public folders are more for static content than anything else.
I'm not really storing that many files yet, and some of them are only temporary anyhow, so this method will hold me over until I move to something like S3.
Please note:
(1) You need to give your Meteor user permissions to access the outside-the-project directory.
(2) Consider that this will take up space on your OS Instance HD.
(3) You'll need to use Node.js for file system calls. These calls are not wrapped in Meteor Fibers, so you're on your own in terms of async/sync programming.

How do I obtain the path of a file in a Meteor package?

I know how to get the current directory from a Meteor package, but how do I get the path of a specific file in the project?
node's __dirname and __filename don't work in Meteor.
It is complicated.
meteor run copies your project files to a tree of directories inside <project-dir>/.meteor/local/build, reorganizes them in non-obvious ways (e.g.. the private subdirectory in the original tree becomes the assets subdirectory) and mixes it in with various npm modules to create a bundle that can be executed as a nodejs project. Indeed, to avoid duplications, there is a .gitignore file automatically set up in the .meteor directory that tells git, if you use it for version control, not to copy the .meteor/local directory.
The original project directory gets watched in case you change a file. The change then gets copied into the current project build directory and the project rebuilt.
If you deploy to a remote system, the build gets copied to a server and then run.
process is usually a defined global server-side object, and works according to the node.js API, because the meteor server code is ultimately running in node.js.
So you can run console.log(process.cwd()); in your server-side to obtain the current working directory for the server process, usually something like:
~/<meteor project directory>/.meteor/local/build/programs/server
This suggests that when meteor run is done locally, original project files are in ../../../../../, but don't use that as it may change in the future.
Instead, for the directory containing the original project files, you could use:
baseDir = process.cwd().replace(/\/\.meteor.*$/, '');
This will get the working directory, and truncate everything beginning with /.meteor
This won't work for a server deploy, though, because the original project tree is not needed on the server, only the build. Files that aren't intended to be client or server code could possibly be stuck in the private subdir, which as I mentioned becomes the assets subdir in the build. Ways to currently find files in the build is either manual inspection .meteor/local in a local run, or use of a JS library that calls or imitates gnu find.
Since you mentioned packages, I note that in the build, server-side package code finally ends up in:
~/<project-dir>/.meteor/local/build/programs/server/packages
and client side in:
~/<project-dir>/.meteor/local/build/programs/web.browser/packages

Deploy node.js with zero downtime using naught

I started using naught for node.js deployment (https://github.com/andrewrk/naught).
I have a folder in Ubuntu Server containing my node.js(express) app.
I deployed it using "naught start app.js" from this folder.
Now I would like to redeploy/update my code with zero downtime.
What should I do?
Suppose I have my code on a git server, do I "git pull origin master" in the same folder and then "naught deploy" to deploy the new code? Or maybe I need to pull the new code to a new folder and deploy the new code in another way?
Pulling the latest changed from Git and calling 'naught deploy' should do the trick. You don't need to clone your code a different directory.
Notice that the 'deploy' command expects an .ipc file, and by default looks for it in the same directory from which you called deploy. If, when starting naught you specified a different location for the .ipc file, then you should call deploy with that location.
So for example, if you did:
naught start app.js --ipc-file /var/run/naught.ipc
Then when deploying use:
naught deploy /var/run/naught.ipc
At BigPanda we use naught in production this way, and it works perfectly.

Categories