I am trying to push a project I created using the Yeoman's angular generator template to a server.
This is my project -
This is in my app folder -
This is the node-modules folder. For some reason, Yeoman has installed several node-modules. I am not using all of these.
The list goes on. This is just a small snippet of what's in the node-modules folder.
In order to push to the server, I am using grunt build. This generates a dist folder with the following content -
.
However when I navigate to my views, (e.g. reset-password), I get an error that this file is not available.
I am guessing this is because the dist folder doesn't have the views folder that the app folder does.
My final requirement is I want to push this project to the server, so that it is accessible to anyone. I don't want to push all the node-modules because I am not using them.
UPDATE -
This is the content in dist/scripts/ -
In the script.2a4ac124.js file, all my views are referenced but when I try to navigate to - file:///Users/proj/Documents/sso/dist/reset-password I get a file not found error, but when I navigate to file:///Users/proj/Documents/sso/dist/index.html#/ I see the index page.
installing node modules is normal - it installs development dependencies, which will be used in the grunt tasks that Yeoman creates. The reason there are so many is because the dev dependencies have their own dependencies that need to be resolved.
reset-password navigation error is most likely some build error, though it is difficult to tell just from the description. Yeoman converts the view files into angularJS templateCache and puts them into the concat/uglified js file (usually the app-.js file). First see if they are there. If they aren't, the view files aren't getting build. If they are there, it could be that the templates are incorrectly cached, or it could also be something else totally.
To deploy your application, simply copy the contents of dist folder to wherever you are deploying. You don't need the node_modules, since they are only used for performing dev. tasks.
Also,
Your screenshots show a SignUpCtrl.js file at the app root. Yeoman scaffoldings, whichever one you are using, usually aren't designed to have script files at the app root. Try putting it back inside the scripts file first.
Related
I have simple React application and I want to add SSR in Express.js.
I made a bit of a gaff in the beginning and in my repository I just have a frontend folder and in it the whole React app with typescript, babel and webpack configured.
I haven't played with SSR yet, so I'm curious, if I want to make such a server and have its file in the folder next to the frontend folder, would I have to install and set all the dependencies I made inside the`frontend folder, and only then create the server.js file ?
Then in the middle of "frontend/src" I would have 2 files - index.tsx (with React.render() method), because I would like to be able to run the application also without the server. And 2nd file would be indexServer.tsx with React.hydrate() method, which would go to server.js file (i.e. would be for generating application by server). Is this concept right ?
Link to my github repo with this react app: https://github.com/poldeeek/spider-game
If I want to make such a server and have its file in the folder next to the frontend folder, would I have to install and set all the dependencies I made inside the`frontend folder, and only then create the server.js file ?
You'll probably need to re-install all the dependencies if you choose to setup two separate folders like that. I would recommend putting server.js in frontend/server, which can then use the same node_modules as your frontend/src/index.js is using.
Then in the middle of "frontend/src" I would have 2 files - index.tsx (with React.render() method), because I would like to be able to run the application also without the server. And 2nd file would be indexServer.tsx with React.hydrate() method, which would go to server.js file (i.e. would be for generating application by server). Is this concept right ?
There is no right or wrong answer here. If this setup suits your needs, then go with it. The only challenge with this setup is that you have to configure babel and webpack to point to two different files: index.tsx (in case you don't want the server) and indexServer.tsx (in case you want to include the server).
I was recently working on a Vue.js project and I am done with the "Beta-Version". I want to deploy my website to an online server and share it with the world. I used npm run build to generate the scripts in the dist folder, and now I want to upload the files to the server, but I doubt that all the files are necessary to be uploaded. I guess I should remove some files that don't effect the user experience.
The Question: What are the files that can be removed before deploying a Vue.js project?
Note: I'm not talking only about the dist folder, I'm taking about removable files and folders in the root project directory, that contains dist and package.json and node_modules.
The purpose of build process is to put any and all files and nothing else necessary for deployment into a folder, in this case, dist folder.
Oops. This was meant to be a comment.
You really shouldn’t delete any file in dist folder unless you know for sure you don’t need it.
If you do know that certain file doesn’t belong, it shouldn’t be there to begin with.
But unless you modified build portion to add something you don’t need, it most likely doesn’t contain any that shouldn’t be there.
I can build and serve an Angular 5 project with ng serve and view it in my browser. I'd like to move the files onto a docker container because my final app needs to have a php backend.
When I move the same file system that runs with ng serve to a docker build and try to navigate to it, I receive a server error.
I know the container works properly because I can serve PHP files to the browser at the respective localhost port without any issues. So it needs to be something with Angular that is causing the error.
I've noticed that the ng new angular-tour-of-heroes project doesn't have an index.html in the root project directory. When I move the one in the src/ folder to the root, I still get nothing in the browser.
How can I serve an Angular app using Docker instead of ng serve?
This answer will be two parts since it sounds like you may not be familiar with the build process.
Building
This is more general to most JavaScript frameworks. There is usually a "build" process that will produce the static web application in some way that it can be served by a web server.
In the case of Angular, it is ng build. You can learn more about the command at https://github.com/angular/angular-cli/wiki/build. The ng build command would create a dist directory in your project where the built HTML, CSS< and JavaScript lives. The files in this directory are what you would push to your web server to serve.
Docker
Now that we understand how to get the source of the web application to serve, we want to run it as a container. Based on your question, I am assuming that you already have a Docker image with a web server. In this case, you could copy the dist folder to the same location as the existing Dockerfile that builds your web server and add a line to your Dockerfile such as:
COPY dist/* /my/webserver/root
If you can provide more information about your existing image, Dockerfile, and environment I could provide a better example of building and producing the Angular application to the final web server image.
Though, you don't necessarily need to serve the Angular application from your PHP application. If your Angular application is connecting to the PHP application they could still be separate Docker images and containers that are linked together.
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
My question is partly technical and partly about deployment strategies and workflow. I built a project using Require JS. It includes a number of distinct js modules, and is built upon Kirby CMS. The directory structure of the project is something like this:
project
assets
styles
style.css
js
scripts
script1.js
script2.js
script3.js
vendor
app.js
images
fonts
content
...
kirby folders
....
The file app.js is called in the footer of my site's page like so:
<script data-main="/assets/js/app" src="/assets/js/vendor/require.js"></script>
It configures RequireJS by calling the requirejs.config() function and then calls the main script file that loads everything else using RequireJS's requirejs() function.
I've used RequireJS' s optimization tool to compile the project in such a way that the optimized files are all dumpted into a directory called dist (a name I just picked up from this tutorial). So in the end dist contains a replication of every directory and file under assets, only optimized, and the file app.js is a concatenated and optimized version of all the js modules that I have in the project. So far so good.
What I am unsure about, however, is how I'm the supposed to make use of this new secondary version of all the code. What for instance if I want to deploy a version of the site to the production server without all the source js files? Each time I deploy the site, I would need to go through my code and in every place that I referred to files under the assets directory, I would need to replace that with dist. I deploy using git and beanstalk. One way to do this would be to manage different branches for staging, production, and development, in which the production and perhaps staging branches have references to the files under dist, but this seems awkward.
So my question is given this kind of optimization set up, which if you look at the tutorial linked above is one way to do this, how then do you manage the switch to the optmized version of everything seemlessly, without having to go back into your code and change everything up? Is there some key part of the process that I'm missing here?
Each time I deploy the site, I would need to go through my code and in every place that I referred to files under the assets directory, I would need to replace that with dist.
I've looked at the tutorial you've linked to and do not see how it is true for the tutorial. The tutorial does not use absolute paths, so should be deployable from dist just as well as from the directory that contains the pre-optimization sources. If you cannot do this for your application, that's because you've done something different from the tutorial. Your script tag, for instance, shows absolute paths.
So the solution is to design your application to avoid absolute paths. This way, you won't have to change paths when you deploy from dist. I'm using this very method to deploy optimized and non-optimized versions of one of my apps.