I have an electron app which runs with no problems when using electron www from the command line, however when i use electron-package to build a standalone binary, the built binary produces a console error as it cannot find certain front-end libs (angularMoment being one of them). Electron-package also fails to include other folders which contain the HTML templates for the app.
The project folder looks like this:
/electron
/www
/app
/css
/img
/js
/node_modules
- index.html
- main.js
- package.json
I am running electron-package from within the www folder and the process completes without errors however as mentioned earlier certain folders within the lib folder get missed off / ignored.
Any ideas why this is happening?
I recommend using the open source electron-forge to kickstart, build, and run your app. It has saved me heaps of time configuring, debugging, etc.!
When developing, did you install angular-moment by using the npm install angular-moment --save command?
Related
I am working on a VueJS web app. One of the modules it uses is a wrapper for a javascript library installed through npm and packaged to integrate into vuejs. It does not quite fit our needs, we need to add some functionality to it, so I want to fork it and edit it.
The repo has two folders: src and dist.
As far as I understand, src is the actual src code while dist is a minified version for distribution. Questions:
If I want to edit it, how do I deal with the contents of /dist ? Do I delete it?
Do components installed through npm use the /src/ version or the /dist/ one?
If I delete /dist, work on the /src code, how do I recreate /dist based on the modified /src files?
Thank you.
Based on your questions, I would suggest you get a bit more familiar into your stack and how to actually build your appication.
Generally speaking the /dist folder contains automatically generated files, which may be uploaded to a webserver of your choice. Since you are using VueJS, you should be able to generate these files by running npm run build.
If I want to edit it, how do I deal with the contents of /dist ? Do I delete it?
As I already mentioned, these files are automatically generated by running npm run build. Therefore everytime you run this command, everything in /dist, will be automatically updated.
Do components installed through npm use the /src/ version or the /dist/ one?
Your working directory is always /src. Dependencies can be used like in any other application (this example uses Axios, which is a http client):
import axios from 'axios';
const httpClient = axios.create({ baseURL: 'https://api.something.com' });
httpClient.get(/* ... */);
If you are a beginner and are not 100% sure about how to use depencencies, I highly encourage you to read this article: An Absolute Beginner's Guide to Using npm
If I delete /dist, work on the /src code, how do I recreate /dist based on the modified /src files?
You do not have to delete anything in /dist. Simply running npm run build automatically will add the latest changes.
Please keep in mind that running npm run build is only relevant for your production environment. For your development environment you always want to use a dev server, which can be started with npm run serve.
I am building a multi page site that uses SASS along with the commons like HTML, CSS JS and webpack. Which works just fine locally when I run npm start, which triggers my webpack.dev.js please refer to the screenshot npm start.png.
Similarly when I run the npm run build command, in my project I would like my ./sass/main.scss file to get compiled and bundled into the dist folder, which will then serve and style all the html pages that are generated in the ./dist folder. Instead when I run the npm run build command it does create the ./dist folder, the html files and css files but the style is not injected into the html.
So to summarise I don't get any specific error as such but instead I don't get a desired outcome after running my webpack.prod.js as mentioned above.
So the problem is in the plugins and the module section of the webpack.prod.js, that is the way I have setup to spit out the css, js and the html pages
The repo has all the files including the ./dist folder and screenshots of the commands npm start and npm run build and the file structure as well
My github repo is https://github.com/kekir/WP-experiment
hope that helps
thanks again
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
My app has a client and an API in the same repo. The API side is built with slc build --npm, while the client is built with npm run build as triggered within the slc build command. I am trying to build the deployable .tgz file and exclude the client/ and build/ artifacts (among a bunch of other stuff that I don't necessarily want on my API servers).
Am I missing a configuration setting?
My .npmignore clearly has entries for
client/
devops/
dist/
yet after building if I untar the archive, everything listed in .npmignore is still included. Is this just not supported?
I guess slc build --npm is not running the actual npm pack command internally and just doing a custom thing.
You are correct that it is not running npm pack. It is actually using a module that was explicitly created to ignore the .npmignore file in your module as well as any dependencies.
The reason this was done is because many modules with binary add-ons are configured to not publish their compiled parts, and this makes it impossible to bundle those packages with their binaries pre-compiled so that they can be deployed to an environment that doesn't have a compiler.
It sounds like the behavior could use some refinement, like only ignoring the dependencies ignore files.