I have an Electron JS application that uses a local sqlite database. The sqlite database is a file within the project folder structure (lib folder). The application works just fine during testing, but when I build the app on Mac, and launch the .dmg file, it gets an error saying it cannot find the .sqlite database.
Is there a way to get this to work with the sqlite database I have in my project? Or is there a simpler way to do local storage in an Electron app?
Thank you.
I found out this can be accomplished by writing the SQLite file to the local user's directory:
const electron = require('electron');
const path = require('path');
const userDir = (electron.app || electron.remote.app).getPath('userData');
const dbPath = path.join(userDir, 'mydb.sqlite');
You must add buildResources extraResources in package.json to grab the SQLite file in production.
"build": {
"appId": "com.app.app",
"productName": "Electron APP",
"files": [
"build/**/*"
],
"directories": {
"buildResources": "build"
},
"extraResources": [
{
"from": "./db/",
"to": "db/",
"filter": [
"**/*"
]
}
],
},
Related
I'm currently trying to debug a Next.js Application inside a NX monorepo.
I have enabled the Auto Attach setting in VSCode's User Settings.
When I start the Application using the serve command, I can see output in the Debug Console and also print out the current process by typing process or console.log(process) into the Debug Console.
However, I cannot set any breakpoints in the server side code, for example in getServerSideProps.
I checked Next.js Debugging Documentation for the missing pieces, and tried setting the NODE_OPTIONS='--inspect' in my Next.js Application via .env file.
Update: Seems like it's a missing feature on NX.
Got it working, thanks to the information from this Pull Request.
.vscode/launch.json
{
"version": "0.2.0",
"resolveSourceMapLocations": ["${workspaceFolder}/**", "!**/node_modules/**"],
"configurations": [
{
"name": "name-of-the-app – Server",
"type": "node",
"request": "launch",
"runtimeExecutable": "yarn",
"runtimeArgs": [
"nx",
"run",
"name-of-the-app:serve",
"-r",
"ts-node/register",
"-r",
"tsconfig-paths/register"
],
"outputCapture": "std",
"internalConsoleOptions": "openOnSessionStart",
"console": "internalConsole",
"env": {
"TS_NODE_IGNORE": "false",
"TS_NODE_PROJECT": "${workspaceFolder}/apps/name-of-the-app/tsconfig.json"
},
"cwd": "${workspaceFolder}/apps/name-of-the-app/"
}
]
}
Note: I'm using yarn. You might have to replace it with npm instead.
I am truing to get a existing .Net functions app runing locally. It has been developed on Windows with Visual Studio, but I am on a Mac (M1 CPU) and using VS Code. I am pretty new to .Net I am struggeling to figure out what needs to be configured to get the project running.
I have added a launch.json:
{
"version": "0.2.0",
"configurations": [
{
"name": "Attach to .NET Functions",
"type": "coreclr",
"request": "attach",
"processId": "${command:azureFunctions.pickProcess}"
}
]
}
and a local.settings.json:
{
"IsEncrypted": false,
"Values": {
"AzureWebJobsStorage": "UseDevelopmentStorage=true",
"FUNCTIONS_WORKER_RUNTIME": "dotnet"
}
}
and there is a tasks.json already in the project:
{
"version": "2.0.0",
"tasks": [
{
"label": "clean (functions)",
"command": "dotnet",
"args": [
"clean",
"/property:GenerateFullPaths=true",
"/consoleloggerparameters:NoSummary"
],
"type": "process",
"problemMatcher": "$msCompile",
"options": {
"cwd": "${workspaceFolder}/Naboor.Statistics"
}
},
{
"label": "build (functions)",
"command": "dotnet",
"args": [
"build",
"/property:GenerateFullPaths=true",
"/consoleloggerparameters:NoSummary"
],
"type": "process",
"dependsOn": "clean (functions)",
"group": {
"kind": "build",
"isDefault": true
},
"problemMatcher": "$msCompile",
"options": {
"cwd": "${workspaceFolder}/Naboor.Statistics"
}
},
{
"label": "clean release (functions)",
"command": "dotnet",
"args": [
"clean",
"--configuration",
"Release",
"/property:GenerateFullPaths=true",
"/consoleloggerparameters:NoSummary"
],
"type": "process",
"problemMatcher": "$msCompile",
"options": {
"cwd": "${workspaceFolder}/Naboor.Statistics"
}
},
{
"label": "publish (functions)",
"command": "dotnet",
"args": [
"publish",
"--configuration",
"Release",
"/property:GenerateFullPaths=true",
"/consoleloggerparameters:NoSummary"
],
"type": "process",
"dependsOn": "clean release (functions)",
"problemMatcher": "$msCompile",
"options": {
"cwd": "${workspaceFolder}/Naboor.Statistics"
}
},
{
"type": "func",
"dependsOn": "build (functions)",
"options": {
"cwd": "${workspaceFolder}/Naboor.Statistics/bin/Debug/net6.0"
},
"command": "host start",
"isBackground": true,
"problemMatcher": "$func-dotnet-watch"
}
]
}
Should I be able to run this project from the commandline somehow? Do I need to point to a task in the tasks.json?
If I run it with F5 in VS Code, I get this error:
Executing task: func host start
Can't determine project language from files. Please use one of [--csharp, --javascript, --typescript, --java, --python, --powershell, --custom]
Can't determine project language from files. Please use one of [--csharp, --javascript, --typescript, --java, --python, --powershell, --custom]
Can't determine project language from files. Please use one of [--csharp, --javascript, --typescript, --java, --python, --powershell, --custom]
Azure Functions Core Tools
Core Tools Version: 4.0.4544 Commit hash: N/A (64-bit)
Function Runtime Version: 4.3.2.18186
Can't determine project language from files. Please use one of [--csharp, --javascript, --typescript, --java, --python, --powershell, --custom]
Can't determine project language from files. Please use one of [--csharp, --javascript, --typescript, --java, --python, --powershell, --custom]
[2022-05-25T12:24:12.674Z] Failed to initialize worker provider for: /opt/homebrew/Cellar/azure-functions-core-tools#4/4.0.4544/workers/python
[2022-05-25T12:24:12.682Z] Microsoft.Azure.WebJobs.Script: Architecture Arm64 is not supported for language python.
[2022-05-25T12:24:12.991Z] Failed to initialize worker provider for: /opt/homebrew/Cellar/azure-functions-core-tools#4/4.0.4544/workers/python
[2022-05-25T12:24:12.991Z] Microsoft.Azure.WebJobs.Script: Architecture Arm64 is not supported for language python.
[2022-05-25T12:24:13.118Z] A host error has occurred during startup operation 'a0f1f8a3-92f6-434a-9ab1-17055f0828f4'.
[2022-05-25T12:24:13.118Z] Microsoft.Azure.WebJobs.Script.WebHost: Secret initialization from Blob storage failed due to missing both an Azure Storage connection string and a SAS connection uri. For Blob Storage, please provide at least one of these. If you intend to use files for secrets, add an App Setting key 'AzureWebJobsSecretStorageType' with value 'Files'.
Value cannot be null. (Parameter 'provider')
The terminal process "/opt/homebrew/bin/zsh '-c', 'func host start'" terminated with exit code: 1.
I thought that was what the "FUNCTIONS_WORKER_RUNTIME": "dotnet" part of local.settings.json was for?
I am pretty new to this, can anybody guide me on the correct path?
Thank you
Søren
In order to configure VSCode launch tasks etc I would recommend installing the Azure Functions extension from the marketplace:
https://marketplace.visualstudio.com/items?itemName=ms-azuretools.vscode-azurefunctions
Once that is installed you can open the project and it will likely detect the functions project and ask if you want to initiliase for use with VSCode. If it does not then you can use the option from the command palette.
You may also be able to just run func init against the project to initiliase any files that may be missing.
Please ensure any files are tracked in git or backed up before making changes to the existing files
Having worked with Azure Functions on both Windows and Mac (non-M1) I would highly recommend using devcontainers for development. This means you don't have to have the SDK/Runtime/Functions Core Tools installed locally and means anyone using the project can just spin up the container and begin debugging without having to install a bunch of dependencies.
https://code.visualstudio.com/docs/remote/containers
We have tried the same in our local and able to run it successfully.
I believe that you are just missing the configuration in your local .
Here are the steps :-
Make sure the Azure function runtime , Dotnet sdk, storage emulator has been installed in your local . If not you can download from VS CODE extension called AZURITE instead of emulator as it has been deprecated.
In VS CODE install extensions Azure where all the tools will be available , c# (Any language that you want to prefer) & Azure function being installed.
.
If you want to create new project click f1> Select create new azure function . As you have existing file there is no need to point task.json file once the aforementioned has been done test your project by running :
. dotnet build once build succeed run ,
. func host start (If you have existing/new project don't run func init as it will create one more .csproj file and then it may occur to fail)
SNAPSHOTS FOR REFERENCE:-
STORAGE EMULATOR STARTED IN LOCAL:-
For more information please refer this MICROSOFT DOCUMENTATION| STEP BY STEP TUTORIAL TO CREATE AZURE FUNCTION IN VS CODE.
Alternatively, If you want to learn using Visual studio Create Azure function on Macos please refer this MICROSOFT DOCUMENTATION.
How can I pass environment variables to a Gatsby build task in a Google Cloud Build CI process? Using the substitution variables I can make variables available in the cloudbuild.json file but these then need to be available in the build task.
Gatsby uses a .env.production file to hold the environment variables which are then available using the dotenv package. At the top of my gatsby-config.js file I set the path to the environment file as follows:
require("dotenv").config({
path: `.env.${process.env.NODE_ENV}`,
})
Further down the file I use these variables to configure the gatsby-plugin-firebase plugin for Firebase. Given that I need an environment file, I have tried to create one in the cloudbuild.json file before running the build step.
{
"steps": [
{
"name": "ubuntu",
"args": ["echo", "FIREBASE_API_KEY=$_FIREBASE_API_KEY\\nFIREBASE_AUTH_DOMAIN=$_FIREBASE_AUTH_DOMAIN\\nFIREBASE_DATABASE_URL=$_FIREBASE_DATABASE_URL\\nFIREBASE_PROJECT_ID=$_FIREBASE_PROJECT_ID\\nFIREBASE_STORAGE_BUCKET=$_FIREBASE_STORAGE_BUCKET\\nFIREBASE_MESSAGING_SENDER_ID=$_FIREBASE_MESSAGING_SENDER_ID\\nFIREBASE_APP_ID=$_FIREBASE_APP_ID\\nFIREBASE_MEASUREMENT_ID=$_FIREBASE_MEASUREMENT_ID", ">", ".env.production"]
},
...More steps here...
{
"name": "node:14.4.0",
"entrypoint": "npm",
"args": ["run", "build"]
},
{
"name": "node:14.4.0",
"entrypoint": "./node_modules/.bin/firebase",
"args": ["deploy", "--project", "$PROJECT_ID", "--token", "$_FIREBASE_TOKEN"]
}
The .env.production file does not exist when I get to the build step, which I think is because it has been created in the ubuntu container. How can I create an environment file that can be read by the build step. Or is there a better way of passing the variables?
Thanks,
Your first step is wrong, you only echo the command, not execute it. Change it like this
{
"steps": [
{
"name": "ubuntu",
"entrypoint": "bash",
"args": ["-c", "echo FIREBASE_API_KEY=$_FIREBASE_API_KEY\\nFIREBASE_AUTH_DOMAIN=$_FIREBASE_AUTH_DOMAIN\\nFIREBASE_DATABASE_URL=$_FIREBASE_DATABASE_URL\\nFIREBASE_PROJECT_ID=$_FIREBASE_PROJECT_ID\\nFIREBASE_STORAGE_BUCKET=$_FIREBASE_STORAGE_BUCKET\\nFIREBASE_MESSAGING_SENDER_ID=$_FIREBASE_MESSAGING_SENDER_ID\\nFIREBASE_APP_ID=$_FIREBASE_APP_ID\\nFIREBASE_MEASUREMENT_ID=$_FIREBASE_MEASUREMENT_ID > .env.production"]
},
I'm not sure what I did (removed node_modules and reinstalled?) but I used to have auth configured for my AWS Amplify (v0.1.42) project and now it's gone.
My .amplifyrc is configured correctly:
{
"providers": {
"awscloudformation": {
"AuthRoleName": "xxx",
"UnauthRoleArn": "arn:aws:iam::xxx:role/xxx",
"AuthRoleArn": "arn:aws:iam::xxx:role/xxx",
"Region": "us-east-1",
"DeploymentBucketName": "xxx",
"UnauthRoleName": "xxx",
"StackName": "xxx",
"StackId": "arn:aws:cloudformation:us-east-1:xxx:stack/xxx/xxx"
}
}
}
I have an existing amplify/ directory with auth as part of the backend and #current-cloud-backend. I also have a generated src/aws-exports.js:
// WARNING: DO NOT EDIT. This file is automatically generated by AWS Amplify. It will be overwritten.
const awsmobile = {
"aws_project_region": "us-east-1",
"aws_cognito_identity_pool_id": "us-east-1:xxx",
"aws_cognito_region": "us-east-1",
"aws_user_pools_id": "us-east-1_xxx",
"aws_user_pools_web_client_id": "xxx"
};
export default awsmobile;
All of the information is correct, however when I try to execute amplify cli commands it acts like I'm a brand new user. How can I get the amplify cli to use the existing configuration in my project?
This is incredibly frustrating because I can't really afford to create everything from scratch again.
I am working on a node express api which is building a view via react and CSS modules (one CSS file within each component imported directly into the component). The react output is serialised with renderToStaticMarkup() which will be sent back to the requester in the JSON response. I also intend to send the compiled CSS in this response too.
I have a working build process via webpack which bundles my server app to one file. I am also currently bundling my CSS (modules) into one file (with the intention of reading this in later).
I am using webpack with its watch facility as follows (can't use webpack-dev-server as the api requires POST and there is no 'page' to update anyway):
cross-env NODE_ENV=development webpack -w --colors
My issue however is that whilst this all works fine on first compile, as soon as I change any file, I get a webpack error stating that I need an appropriate loader for the imported CSS file.
ERROR in ./src/app/components/Suggestions/Suggestions.css
Module parse failed: /home/me/myproject/src/app/components/Suggestions/Suggestions.css Unexpected token (1:0)
You may need an appropriate loader to handle this file type.
| .suggestions {
| background: blue;
| color: orange;
# ./src/app/components/Suggestions/Suggestions.js 11:19-47
# ./src/app/components/Suggestions/index.js
# ./src/server/middleware/buildSuggestions.js
# ./src/server/routes/index.js
# ./src/server/server.js
# multi babel-polyfill ./src/server/server.js
I have simplified my webpack config as much as possible and still get the issue. My simplified config (not extracting css to file and no PostCSS) is as follows:
webpack.config.babel.js
import path from 'path';
import nodeExternals from 'webpack-node-externals';
import PATHS from './config/paths';
// Host and port settings to spawn the dev server on
const HOST = 'localhost';
const PORT = 3000;
const LOCAL = `http://${HOST}:${PORT}`;
const DEV = process.env.NODE_ENV === 'development';
let serverConfig = {
entry: [
"babel-polyfill",
path.resolve(PATHS.src, 'server/server.js'),
],
output: {
filename: 'server.js',
path: PATHS.dist,
publicPath: '/'
},
module: {
rules: [
{
test: /\.jsx?$/,
include: PATHS.src,
use: {
loader: 'babel-loader',
options: {
// babelrc at project root only for compiling this webpack
babelrc: false,
presets: [
'env',
'react'
],
plugins: [
'transform-object-rest-spread',
'syntax-dynamic-import',
'transform-class-properties',
]
}
}
},
{
test: /\.css$/,
use: [
{
loader : 'css-loader',
options: {
modules: true,
importLoaders: 1,
localIdentName: '[local]-[hash:base64]',
sourceMap: DEV
},
}
]
}
],
},
plugins: [
],
target: 'node',
externals: [nodeExternals()]
};
export default serverConfig;
So my question is, why does this work okay on first compile but not on a recompile after a change?
Stranger than fiction!
So I realised that if I run my build without the watcher...
cross-env NODE_ENV=development webpack --colors
and that process had ended, if I edited a file I still saw the error!!! Even though there was supposedly no watcher running. I left that terminal window alone with no running process, opened another terminal and edited a file within my src directory using vi (closed WebStorm in case it had some odd watcher running). Incredibly, the error popped up again in the original terminal window!!!
So it seems my issue was caused by a rogue webpack watch process that hadn't been killed properly. Couldn't find the process to manually kill it so had to do reboot. Literally hours lost on this bizzare issue. At least my whole build process is working again.