Background:
We are developing an electron application which gets bigger and bigger over time. We've separated our web-app (renderer process) and the native wrapper process (main process) into separate projects, which is a good start, but not enough-
We have different teams working on the same electron infrastructure and would like to split the code into separate repos, each managed by a different team, and all of them are being loaded into the main infrastructure project of electron.
Problem:
At first, it sounds simple - create an npm package for each electron module (one for each team) and import those packages in the main electron project, that manages all of them and builds the final electron app. The problem is that those electron packages should be familiar with 'electron' package, and should somehow use the same version of this package. Since keeping track of the package the main electron project uses and updating it manually in every module each time we want to increase it's version is bad for scaled up application, we want to be able to sync them in a better way.
(Bad) solutions I could think of:
Pass the electron instance from the main electron app to the inner packages (in an init function) and use it instead of using the installed 'electron' package. It solves the problem of syncing electron versions, but when the main app updates the electron version - the packages won't be familiar with it and might break in case of incompatibility.
It sounds like no matter what I do, I can't decouple the projects and they must communicate (manually) to work properly. Is there any architecture design method I'm missing that could help me split one electron projects into multiple ones?
We are created #our-company/our-product-common package with common dependencies and configs (electron, typescript, lint rules, global constants). If we want to update electron or typescript we update versions in *-common package.
Or you can create #our-company/our-product-electron package which just reexports electron.
Related
The most popular boilerplate for vue/electron usage, seen here: https://github.com/SimulatedGREG/electron-vue
Is outdated, and only uses vue cli2.
The quickest, and easiest way I've found to get Vue and Electron playing nice together is vue electron-builder.
To use, set up a project with Vue CLI3 using
vue create my-project
then CD into that directory, in this case "my-project", and run
vue add electron-builder
This sets up barebones scaffolding that allows vue and electron to play nicely from the get go. You can test your work by launching an unbuilt test version using
npm run electron:serve
and, when you are ready for deployment, may use
npm run electron:build
to build. This vastly simplifies the process, seen elsewhere, of dealing with a giant over engineered boilerplate or trying to write out relative pathing so your builds and dev environments both work identically.
This repository contains the starter template for using vue-next with the latest electron.
I started to learn electron & vue by the great project electron-vue. This project is also inspired from it.
https://github.com/ci010/electron-vue-next
As per the official website, the correct way to save electron files is:
npm install electron --save-dev
Electron is actually required for running the app (quite literally: require()) and this goes against the top voted answer here. So why do we make this exception, if this is even one?
The fact that you require a package is irrelevant to whether it should be considered a dependency or a devDependency (in the npm sense). E.g. many projects use webpack API (i.e. const webpack = require('webpack')) but list it as a devDependency.
The reason is also explained in the post you link to: when you publish your package, if the consumer project needs other packages to use yours, then these must be listed as dependencies.
If your package uses some modules only for build, test, or bundles them into a dist file (i.e. what will be used by the consumer project), then those modules should not be mentioned in dependencies. We still list them in devDependencies for development.
Now in the case of an electron app, there is little chance you will consume your app as a node module of a consumer project, therefore the above convention is not really relevant.
Furthermore, we fall in the case where the electron package is bundled as part of the built output. There is no need for your user to get electron from npm to use your built app. Therefore it matches well the definition of a devDependency.
That being said, IIRC some electron packagers bundle your dependencies into the built app, so you still need some rigour in filling this list.
Cause those binary won't being used when you actually packaging into installer. Most of installer / packager for electron will build package with electron binaries, instead of using dependencies.
My team is building a large React application. I am wanting to know if what we are trying to accomplish in regards to build and deployment are possible with Webpack.
Let’s say our team is building Google Admin. There are 4 modules/app within the admin that 4 different teams are focused on. There is then a console application that is the entry point to these 4 modules/apps. We want to be able to work on each of the modules independently and be able to deploy them independently.
How we have it setup right now is there would be 4 separate applications that are dev harnesses to build these modules. We build them and copy the distribution .js and .js.map files to the console's ./modules folder. We would reference these modules lazily using System.import.
Is it possible, while the console app is built and in production, to “swap out” the module-one.js and module-one.js.map files that the console depends on without having to rebuild and redeploy the entire console app?
Goals:
Do not package these apps for npm. This would definitely require the console app to update and rebuild.
Build any module and deploy just that specific module to production without having to rebuild the console application.
Do not redirect to separate SPAs.
I tried my best to explain the goal. Any input would be much appreciated. I have found nothing in my search.
webpack loads the modules into memory and watches the filesystem for changes, as long as webpack is running you shouldn't have an issue replacing any given module. However webpack will attempt to build the entire in memory bundle with each module change (as it has no way of knowing that your module is truly independent). The only thing I can thin of would be to write a shim between the console app and the modules that watches the files (like webpack) but only replaces the in memory version of the local file that was changed. Reading this I'm not even sure if it makes sense to me...
I have a single page application written in JavaScript ES5 and Angular 1.x, Twitter Bootstrap, UI Router, and several other dependencies. It currently has no modules and no build system and only minimal minification. All code just lives in the global namespace.
The app started out as a prototype and having no build system was fine at first, but now its bigger and not having a proper build system starts to create all kinds of problems.
I would like to transition this app to a webpack 2.x world, as that seems to be the most promising build system right now. But I do not really know where to start.
Ideally I would like to do this gradually, such that I do not have to migrate all files at once.
I have experimented with Webpack 1.x and 2.x for a while, and also created a small prototype that uses Angular 1.x, but I still do not see a way to do the migration step by step. It looks to me as if switching to webpack is an all-or-nothing decision.
I'm trying to build an application that have to run on Windows(PC), Android and iOS.
For this, I will use Electron (for Windows) and React Native (for mobile plateforms). Both will be built with React and Redux. This way, I will be able to implement the logic in Redux reducers and middlewares and use them in both projects.
From now, I have done a POC for the Electron app using webpack. The reducers are currently directly in the app code. I want to extract the Redux relative code in a seperate package to allow me using it in a the React Native project.
I can make an npm package for my Redux module containing the reducers and the middlwares but this way, when I will compile my application, webpack will not compile my seperate package, it will use the precompiled version.
So What I want is to be able to make a separate package but still compile it at application compile time (because it is still in developpement and the dev is very closely related to main application dev).
Do I have to do it only with npm or with webpack as well ?
I'm pretty new to the Javascript dev stack.
I think you have different ways to handle that problem.
You can use NPM package. But in code of package, you will store not only original source code, but compiled code too. I mean before publish that package, you'll need to compile it in normal ES5 code.
I think you can use submodule system provided by Git. You should have separate repository with common code of your reducers. And in each project (Electron, RN, etc.), you will have a directory with git submodule. Webpack should compile code in that directory normally without any problems.
UPD:
About submodules you can read nice article here: https://git-scm.com/book/en/v2/Git-Tools-Submodules#Starting-with-Submodules
In few words, in project it will looks like:
cd yourProjectFolder
git submodule add https://github.com/TalAter/awesome-service-workers submoduleDirectoryName
It will clone repository to your project, and create .gitmodules file. Code from submodule will not exists in current project repository. In remote repository it will contain only link to submodule, but on your machine, you will have full code and you will be able to compile it.