First of all, I am generating an electron native application using electron-builder, npm and npx.
The next commands/steps are being executed to compile and generate the electron native application:
npm run build -- --prod --build-optimizer (to compile app)
npx electron-builder build --windows (to generate an electron windows app)
Later, I obtain a myApp folder which contains:
/win-unpacked
electron-builder-effective-config.yaml
myApp.exe
My application uses the node_modules folder which contains all node dependencies used in my application.
My question is: are there any way to unpack the native application or similar and patch new changes inside node_modules?
After perform an investigation, I have discovered that node dependencies are packed in system cache inside an app.asar file which contains a dist folder with some .js files.
In developer tools:
Inside app.asar:
Are there any way to "deploy" node modules folder with the aim to perform patch operations of each package and change the code inside node modules folders?
I will appreciate any kind of help.
Asar is a read only archiv format, so you cant patch any files in the archive.
But what you can do is to disable the asar option in your build config.
So in your package.json define it like this:
"build": {
"appid": "........",
"win": {........},
"asar": false
}
if you build this, there is no asar archive anymore and you can overwrite any file...
what you can also do is using asar programatically. So you can unpack the asar archive, updating files and package new archive. See here how you can use it
Contrary to what is being said here, patching a .asar archive is totally possible. I have published a library on NPM called patch-asar that does specifically this.
Related
I created a yarn workspace alongside typescript as such.
I have three folders with their own package.json
/api
/client
/lib
The point is to share code from lib between API and client. In an API file for example I can do
import {User, UserAccount} from '#myproject/lib'
There are problems with this.
I need to build lib each time I change something
/api's build files point to C:/myproject/lib/build/index.js
Since I would like to deploy the project to heroku by just pushing what's in /api/build, this will fail because it can't find the files in /lib/build. Maybe I can push both build folders up to heroku, but what I was hoping for was some magic that compiled all /lib/src files into /api/build. My /client is running in expo which I assume uses something like webpack or I don't know what, and it seems to do this. Do I need to use webpack to acheive this or can I do it with yarn workspaces and typescript?
In tsconfig.json of client and api packages you need two configs, if you don't already have them:
In "compilerOptions" make sure you have "composite": true
Add "references": [{ "path": "relativePathTo/lib" }]
When you run tsc, run it with the --build (-b) flag, like this: tsc -b. This will build the active package and any package in references. More on TypeScript Project References.
This fixes your problem in development. Depending on your project configuration, you may need to do more things to put it through the CI.
I have a React Native app built using TypeScript, and I would like to also develop a number of CLI tools to help developers and 'back office' folks, also using TypeScript. I would like these to live in the same monorepo.
Based on advice from colleagues and my own research, I have tried doing this by creating a subfolder in the repo, and creating a second package.json (and all the other config files), and npm install-ing as if it were a completely separate project. It didn't take long for this to become a total mess, primarily with duplicate imports where one thing mysteriously seems to import modules from the other targets' node_modules, but also just remembering to re-npm install all the different subprojects before each commit, etc. It gets even more confusing with the TS build folders lying around; they're another place for people to import the wrong thing from. The confusion caused by this approach has been a significant drain on productivity, and it feels like there has to be a better way. So that's the question:
What is the best practice for building multiple TS/Node targets (and by "targets", I don't mean ES6 vs ESNext, I mean in the C/C++ sense: multiple output "programs", so in this case I want it to both create the bundle necessary for my RN app, but then also generate a CLI executable.) that all share code with one another, from a single monorepo?
If it matters, I am also using Expo.
You're essentially describing a monorepo. pnpm has fantastic tooling out of the box for this.
Download the pnpm CLI and install it:
$ npm i -g pnpm # Download pnpm
$ mkdir monorepo # Create a new monorepo folder
$ cd monorepo
$ mkdir packages # This will be the folder where you add your
# apps, libraries, etc.
$ touch package.json # Create a package.json
$ echo "{}" > package.json
Create a pnpm-workspace.yaml file and add the following:
packages:
- 'packages/**'
Congratulations. You now have a monorepo where you can add multiple apps. Here's how it works:
Every folder under packages that has a package.json file is now a Node app that you can control using pnpm from the root of your workspace.
When you run pnpm i from the root, it will install all of the dependencies for all of your apps and libraries.
You can even install libraries that you create locally without needing to run npm link, or deal with adding file:../ to your package.json or any of that mess.
pnpm also supports running scripts across all of your repos at the same time.
I made an example project for you to look at. In this example, you'll notice I created a library named my-library and a dependent app named awesome-app. When I ran
$ pwd
~/stackoverflow/packages/awesome-app
$ pnpm i my-library
pnpm knew to pick up my workspace library automatically:
{
"name": "awesome-app",
"dependencies": {
"my-library": "workspace:0.1.0"
}
}
Note the workspace:0.1.0 that matches the version of the package I have in my repo.
I love pnpm. It isn't without its faults, but I've been very productive with it. There are also other alternatives, such as Lerna, and npm and yarn support their own workspace protocol. I just find pnpm to work the best and has the least amount of ceremony.
Enjoy.
I'am trying to compile a Node.js package (github action) into single file using #zeit/ncc NPM package, but some dependencies don't get copied to dist directory.
For example my package depends on 7z-min and nightmare NPM packages. Running ncc build index.js build single file successfully and copies 7z binaries for each platform correctly but nightmare electron binaries don't get copied. Only a file called path.txt containing dist/electron.exe.
When running my github action it fail to find electron executable.
Most probably you might have not imported the package in the JS file.
I'm setting up a gulp build file for a node.js project and I really don't have any experience with either of them.
So basically what I'm doing is simply copying all the code to a deployment directory, but I'm unsure of how to handle all the dependencies that are stored in node_modules. Do you simply copy all of them as well, or is there a more preferred way of doing it?
gulp.task('deliver', function() {
gulp.src('src/*.html').pipe(gulp.dest('deployment/'));
gulp.src('src/*.js').pipe(gulp.dest('deployment/'));
gulp.src('src/games/').pipe(gulp.dest('deployment/'));
});
The standard way would be to have a package.json file that lists all your dependencies. Then as part of your deployment process run npm install which will go through your package.json and install any necessary packages in the node_modules folder.
Does anyone know how to get a hogan.js 3.0.0 dist file?
The files at https://github.com/twitter/hogan.js are source files that should be compiled with Node.js in order to create the distributable. My question is how to build the source files with Node on Windows, or a link to a pre-built distributable file.
The dist file is mentioned here: https://github.com/twitter/hogan.js/blob/master/lib/hogan.js#L16
Hogan uses a Makefile to create dist builds and do testing. This can be envoked by running make dist from a NIX terminal. https://github.com/twitter/hogan.js/issues/156
If you want to avoid using the Makefile, because you are running node.js from a Windows command prompt or for whatever reason, you need to create a ./dist directory in Hogan's root directory where the package.json is, then run node tools\release.js.
Make sure you've installed the dev-dependencies with npm install in the same directory as the package.json first.