is it dangerous to keep the folder node_modules on the prod server after building the app.js? Or should I delete the folder after building?. The node_modules folder is not public.
Welcome to StackOverflow, dfgdghjezfghfgdh!
Generally speaking, as the folder is not public, you don't need to worry about it existing in the file system. Depending on how your project is built you might even require it in your production environment as well.
Hope this helped.
If your build process uses webpack (or equivalent) to generate the distributable js, you dont need to keep node_modules at all.
Related
I ran this command to create a ReactJS app
npx create-react-app learningapp
This created several folders now, I dont know which of them are important. I mean I dont know their purpose.
Can anyone explain their purpose in short?
node_modules -- very important, as this will contain all the npm packages and their entire list of dependencies installed.
public -- very important, contains the static files served by your web server.
Index.html -- the index.html file where your react app will inject elements into. I believe this is the only "essential" file.
The other files in this folder will contain logos and manifests if you'd like your webpage to be able to be installed as a mobile app seamlessly. The manifest.json file holds the information about what the app icon and such will look like.
Favicon is the tiny logo you see in your tab title
robots.txt will have the instructions for bots visiting your website. Read about it here if you'd like (https://www.cloudflare.com/learning/bots/what-is-robots.txt/)
src -- very important, will contain your source code. If you want your app to do anything at all, it wouldn't be very wise to delete this folder. If you want to rename this to something else, you can, but you'd have to mess with the webpack configurations. So, not worth the little extra effort. However, you may alter the folder contents.
Unless you want performance monitoring and are writing tests for your app, you can safely delete the test file and the report webvitals stuff. You can make your test files somewhere else too, it doesn't matter if it's here. Just make sure you configure your testing library so that it looks for the correct files.
The rest of the files in this folder can be modified all you like, but try not to touch index.js unless you want to go mess with the webpack configs to change the entry point. Webpack looks for index.js as an entry point to build its dependency tree during compilation.
.gitignore -- this is the files/folders you can tell git to ignore when tracking your folder. A usual candidate for this file is the node_modules folder.
package.json/package.json -- very important, don't directly mess with these unless you know what you're doing. This contains the info about npm packages which your require to run your project properly. A situation where you will need to mess with package.json is when you want to add some custom npm scripts, which is often quite useful.
README.md -- just your readme file which is used to display info about the project on your github repo for example. You can delete it, but just put something on there containing basic info about the repo/ what it does.
I am doing my first angular project and I have to upload it to a Development test server. Problem is that, an Angular project (event in default state) has so many files that it takes a lot of time to upload it.
I investigated and the .gitignore file seems only to be to avoid the commit of the files or folders specified there.
Could you please tell me if there is a way to minimize the number of needed files to upload and install or use them later, in local, in a safe way? Without risks of corrupting the project.
If you are using Angular CLI you can get a production build by doing
npm run -- ng build --prod
in the project directory. This will create a minified, bundled version of your app in the dist folder, ready for upload. You will then need an http-server running to serve these files.
As #yarz-tech suggested, the solution was to remove the node_modules each time I upload it. Then, when someone downloads it and wants to work with it again, must execute npm install. That allows npm to install all the dependencies our project needs, based on what is is specified on the package.json file, which appears not only for Angular projects, but for Node for example.
Thanks to everyone.
To be clear, I am not asking if I need node_modules folder on live host server. That question & answer exists on Stack Overflow already. The consensus answer, in general is YES - I still need the node_modules directory during runtime.
I am also not asking about running npm init or npm install. I understand how that works.
I am specifically asking - do I still need the node_modules directory on the live/host server if I use webpack during my build process? Doesn't webpack bundle all the necessary JS, etc into folder? Can I delete the node_modules folder if use webpack? Or, will I still need that directory during runtime?
This is for a basic front end, client side web application only. This front end calls other API only for backend sevice. This front end web application is being hosted on Windows/IIS.
The site's published code includes static references like this:
<link rel="stylesheet" href="/css/app.css?id=f243e9c6546d420fec1f">
<script src="/js/app.js?id=bf7be8f179cc272c0190"></script>
Ignore the id= part, as I think that's part of the web framework for cache busting.
No, everything is in the bundle after you build. You can take the files defined as output (usually whatever is in the "dist" folder) and stick them on whatever static server you want without the need of the supporting node_modules.
During your web pack build process ,need the node modules folder , because when you import a file from the node_modules , web pack will try to fetch the file from the particular node_module folder recursively.
Once you successfully done with the build you will get a dist package folder with all the bundles for the deployment, it will not contain node_modules folders.
You can test it by using
npm run build
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 have a JavaScript project that includes both frontend and backend codes (NodeJS). This is my production folder structure:
/prod
/server
sourceCode1.js
sourceCode2.js
...
sourceCodeN.js
index.js
/client
bundle.js
ReadMe.md
license.txt
When user hit my /server/index.js, I call express.static(__dirname + '/../client') to serve user js files in /client folder.
I have plenty of frontend js files under /client folder originally, but they are minified and combined into one bundle.js when they are moved to prod as you can see above. I want to add one single config file in JSON format that contains configuration for both my backend and frontend code. But I'm not sure where/how to place it. I think no matter where I put it, my code in /server/index.js can access it with no problem. But for /client/bundle.js, accessing the config file will require another request to the server which seems poor design to me...
Can anyone suggest a way that solves the problem better?
P.S.
I use gulp to minify and combine my frontend js files into bundle.js, I can put the config file in /client folder and use gulp to bundle it together with other js files as well. But that means every time I change the config file, I need to gulp everything again which doesn't make any sense.
PPS.
I agree pulp will work just fine for myself. Another reason I didn't want to use pulp to bundle the config file is that this is an open source project, I'm hoping when someone else uses it and he only wants to change one tiny setting in the config file, he doesn't have to go through the gulp step..
I can put the config file in /client folder and use gulp to bundle it together with other js files as well. But that means every time I change the config file, I need to gulp everything again which doesn't make any sense.
I think it does make sense. Other people do too.
If you're worried about speed, I recommend having two Gulp tasks: Dev and Build.
Dev should watch the source for changes and update the configuration.
Build should do slow things like bundling and minification as well as update the configuration.