Latest meteor version 1.4.0.1. All of a sudden it got stuck on Processing files with ecmascript (for... step. Killing and restarting didn't work, neither did rebooting.
What I tried: meteor reset, rebooting, deleting build and cache folders in project's .meteor folder, deleting and reinstalling npm packages. Removing .meteor in my home folder and reinstalling meteor from scratch. Removing packages, both meteor and npm, that I no longer use.
This is something in my project because creating a new meteor project and running it works fine. The project uses React and has a number of components.
Any ideas on how to fix this?
I solved my issue by process of elimination. I saved a .js file in my client/js/lib folder while working on a feature. At some point later I accidentally saved my meteor application's home page in the same folder! Guess I was too tired. Found the folder and then saw the html and a subfolder with meteor-generated scripts. Removed them and everything clicked. My exact steps:
create a new meteor project, copy over package.json and
.meteor/packages files run meteor npm install and then run the
project with meteor
while the project is running start copying over root app folders one
by one, wait for app to recompile before moving on to each folder
my problem surfaced when I copied over the client folder. Meteor said
refreshing client and got stuck there.
I removed the client folder, killed the process (run ps command, kill
-9 [PID] where PID is the process id with the high CPU time.) and then restarted meteor again
created client folder manually and then started copying client/*
items over one by one
that's when I noticed the app_name.html and app_name folder with a
lot of .js files in it!
I removed them and everything works now. Good luck!
You can try running meteor reset command and then running the project again.
I ran into a similar (but different) problem. I am trying to use plotly.js with meteor. I downloaded the plotly.js file and put it into my client/lib directory. Now, when I try to run meteor, I get the same error being described above. I thought plotly.js worked with meteor? If I remove plotly.js (or rename it to a non js file), meteor works fine...so the issue is clearly with plotly.js
Related
I've been stuck on this issue for some time now.
My Angular project version is 9.0.3.
The #angular/fire version is 6.1.4
I have followed the guide here
The project builds and renders for the local Express server I have.
The problem occurs when I deploy the project to Firebase with a cloud function that will render the application.
Running the command ng deploy gives the below error
Error: ENOENT: no such file or directory, open '/home/teebo/Development/motf/dist/motif/browser/index.html'
This issue is linked to a reported issue here
I have investigated and found that in the project's dist folder, a index.original.html file is generated instead of index.html.
I have opened an issue here with no feedback from the maintainers.
If there is anything I am missing or there's something I can do to circumvent this issue, please share and any suggestions are appreciated.
Any suggestion, comment, anything.
I have found a way to circumvent this issue.
This is not a proper solution for the ng deploy issue but at least I can deploy the ssr function.
Because my dist folder is nested in another dist folder (Which does not include the browser build folder), that is why I was getting the error when running ng deploy. Below are steps I've followed to at least be able to deploy.
Run ng deploy (It will error out with the above error but will build the app and create a dist folder).
Copy the browser folder to the dist folder that does not have it (In my case I have copied it to a dist folder one level up).
Deploy the ssr function by running firebase deploy --only functions:ssr (You can change functions:ssr to whatever name you have named your function).
This worked for me;
It would save time to write an npm script to do all this but then; I am not sure if my firebase/universal config is wrong or there is a bug with #angular/fire.
I usually deploy my vendors with a simple composer install in production.
I would prefer not using composer in production, so I'd need to build the vendors from my machine and deploy them in production.
I could copy the vendor directory but I'll certainly have to install other files like app/bootstrap.cache.php or other autoloader.php
2 questions so:
What are these files I could install/update ?
Are there any known practices to deploy pre-built vendors anyway ?
I would say the procedure is pretty straighforward (at least it works for me that way): To deploy your application, you'd create a new directory, export the code from a tag into it (i.e. you don't export all repository-managing data like a .git directory). You then run composer install --no-dev, which will do some work, and should also run anything that is mentioned in the scripts in the composer.json file.
The result in this previously empty directory goes to the production server in whatever way you like, be it SCP, SFTP, rsync... There is no real "magic" going on here, essentially it is copying of files.
You may want to make sure you can roll back quickly, so I'd recommend to deploy every version into a designated directory, and then link the current version with a symlink. As an example: You had deployed your old version in /srv/www/htdocs/app-1.0 and symlinked the directory /srv/www/htdocs/app to point to this directory. The vhost uses the generic app directory to serve the app.
The deployment will create a new directory /srv/www/htdocs/app-1.1, and putting it live will simply delete the old symlink and create a new one to the new directory. This should put your new version live instantly. Rolling back would mean to delete the symlink and create the one pointing to the old version again.
YMMV, because things like caches will affect the outcome, but this is not in the scope of how and where to use Composer to deploy software.
My current workflow when building a Wordpress site is to create the project in a dropbox folder (so it gets backed up). I then push to a remote REPO.
My problem is that although I can gitignore the GULP dependencies for the repo, I cannot with Dropbox. Each project can generate 500,000 files (albeit tiny), and this really breaks dropbox - for DAYS!
Am I missing something? possible solutions?
Create the project outside dropbox - rely on the repo as a backup :(
Create the project outside dropbox - then clone repo back into DB (without GULP dependencies)?
Install dependencies globally? (npm install -g) - problem is all projects using the same dependencies isn't always what I want.
Thanks in advance
I am starting out on a project that I want to work with my friend in GitHub, so I created the meteor project locally and then added it to github. It added everything except .meteor directory. When my colleague cloned and got the project down since it is missing .meteor directory, he is unable to start working on it. How do we go about recreating .meteor file at another location or am I suppose to include .meteor file into github as well?
* Edit: Since it is brand new project, I asked him to recreate the project locally and copy .meteor directory from the newly created one and copy it to git file location and it worked. Now sure it is the right way though.
You should always check in your .meteor directory because it contains critical information like which meteor version to use and the required packages for the project.
I suspect you may have avoided doing so because of the huge database stored within that directory. Fear not - each meteor project comes with a .meteor/.gitignore which will avoid checking in your DB.
In Chapter 2.5 of Discover Meteor by Tom Coleman, the instructions for deploying to EC2 require me to first bundle the app, move the tarball one directory up, then unzip that tarball again, before running node on the app.
This seems rather a tedious procedure as I'll have to bundle and unzip after every commit to test the app. Also, isn't this just the same thing as moving the entire app one directory up, or does bundling then unzipping do some magic that makes it run right?
Bundling creates a production application, optimized to run on the live environment, while your working directory is more suitable for development. For example, bundled app only have one js and one css file instead of tens to hundreds.
Additionally, bundled app contains all the engine needed to run with plain node, so that you may run it in an environment without Meteor.