I want to create two versions of an app with slightly different content. Therefore I thought about having two "www" directories (lets say "www-foo" and "www-bar") and tell capacitor in the capacitor.config.json which one to use (with "webDir" setting). Also the "appId" should be different then.
So I guessed the easiest way would be to have these capacitor.config.json files with different "appId" and "webDir" settings and when running the build script to specify which config file to use (like it's known from webpack with --config flag). But I can't find any information if it's possible to specify the config file to use for building the app.
Is it just not possible (yet) or am I too stupid to find it? :)
Otherwise I would try to create the capacitor.config.json file with webpack before running the capacitor build script.
I used this article as a guide for my project.
I don't know if exist any option for two or more AppID/webDir in Capacitor.
But understanding you necessity my suggest is create a custom build script in Node.js that change info in capacitor.config.ts (appId) > build (www/www-Two) > sync & copy to platform
Related
I am attempting to load a file from a remote URL during build to be WebPacked. This file is an MDX file and I am using the MDX vue-loader to load this file for use within the Vue application.
The system I am deploying is tenanted with a headless CMS powering some pages across the system. I would like to explore the possibilities of loading the MDX files at build time from a remote URL.
I have placed the MDX files on GitHub Pages with the remote URL passed in as an environment variable at build time.
The result is something like this (the idea here is that I can swap the domain during build to satisfy the tenanted site requirement):
import('https://somedomain.com/content/home.mdx');
This fails with your typical error during build of:
dependencies not found please install them using npm --save https://somedomain.com/content/home.mdx
I can WebPack ignore this import which allows it to build but then it fails to load in the browser as browsers will only load external modules with a MIME type of JS. Not to mention the fact that this hasn't been through the MDX loader so I suspect even if I could get the browser to load it the file would not have been parsed into something usable.
I realise I could copy these files in during the build stage from the remote but I was hopeful that there might be a way to either allow the browser to pull this remote file or WebPack to download this remote file and pack it into the output.
Does anyone have any ideas if this might be possible? Many thanks in advance.
As MDX needs pre-processing during build I think integration with Webpack is the only way.
You can try the SaveRemoteFilePlugin webpack plugin which allows you to download the file from remote to local file system. But maybe it's not what you want as it seems pushing downloaded files directly into dist folder without passing it through rest of the Webpack pipeline...
So probably better option is val-loader which allows executing your own Node scripts during build - here you can find the example which does almost what you need - Fetching Remote data during build
I have developed a vue application and did run npm run build
After that I uploaded the content in the dist file to my webpage but it returned a blank page.
Since I did this for testing I uploaded it to a folder in my public_html/mypage.com/vueapplication To get all the paths right I added a vue.config.js with this content:
// vue.config.js
module.exports = {
publicPath: '/vueapplication/'
}
The application now works but I wounder however:
how do I best publish/upload the application to my site? Just by simply dragging the content inte the right folder?
how can I best maintain my site? Do I need to build again and upload, overwriting my files when everytime I make an update on my site?
And what is the difference between build and deploy your application?
Drag and dropping your code should work. But as your app grows you may want to look into automating this. For instance if you use an S3 bucket you can use the aws cli to automate the upload.
Yes, you should overwrite your deploy folder(s). You need to also take care of deploying different binary files, that have the same name. An example is if you have a global css file (main.css for instance). The file will probably change content between deployments, but keep the same name. Browsers may cache the file so users that downloaded older versions of the file will not use the new one. There are different techniques to handle this, but if you use webpack, it uses cache busting techniques and you should be fine.
Build is the process of transforming source code into an artifact(s). Exactly what this means differs from language to language, platform to platform. In the vuejs world this usually means a couple of js files, a couple of css files and some assets.
Deploying means taking the output of a build and making it available to your users. Again this differs from project to project. In the vuejs world this usually means taking the artifacts from the build and uploading them to an http enabled web server.
We have a situation where we want to be able to start the Nsolid Proxy/Hub from an arbitrary folder. When we try to do this it fails due to not being able to find .nsolid-proxyrc in one of the parent folders.
We took a look at the source code for Nsolid Proxy and it looks like the library it is using, rc, allows end-users to specify a file location, but Nsolid Proxy doesn't accept a CLI argument that allows us to specify it. It should be functionality that is easy to add, but it appears to be a closed source project.
TL:DR; We need to be able to specify the exact location of .nsolid-proxyrc when starting the hub. Is there a known work-around for this or is there a way we could request this feature gets added to the project?
You can specify the configuration file by using the --config flag (from rc) when starting N|Solid Proxy
$ nsolid proxy.js --config /path/to/config/file
By default it will look at the current working directory and then up the folder tree like node_modules then resort to the following locations:
$HOME/.nsolid-proxyrc
$HOME/.nsolid-proxy/config
$HOME/.config/.nsolid-proxy
$HOME/.config/.nsolid-proxy/config
/etc/nsolid-proxyrc
/etc/nsolid-proxy/config
I have two teamcity configurations one becoming my common helpers and reuseable components and my other a website which uses the common project.
I use a third configuration to publish to a test environment.
When the third configuration is run i would like it to get the artifacts from the common project and merge them with the website output and deploy. Am i asking for two much?
This ought to be pretty straightforward.
On ThirdConfig add two artifact dependencies. One whose source is CommonProject, and another whose source is WebProject. When configuring an artifact dependency it will allow you to specify which artifact files are are actually pulled from CommonProject and WebProject into ThirdConfig via the 'Artifact paths'. The artifact files can then be placed into some new folder hierarchy specific to ThirdConfig by using the 'Destination path'. These two options ought to be enough to create the directory structure that is the merging of CommonProject and WebProject. That takes care of the merge part.
The deploy is a bit more tricky. To my knowledge TeamCity does not support any sort of 'copy or upload to external location' function out of the box. For this bit you'll need to create an msbuild script (or batch file, or anything that can be run from the command line). Said script can expect the file/directory structure you've created via artifact dependencies where the root of the structure is the initial working directory of the script, and need only push these files out to your specific deploy location. That 'push' of course is going to be specific to your environment. Ftp, unc share, etc.
We are trying to setup stylecop for a team development environment. So far what we have done is:
Checked the files into source control
Create an environment variable on every machine that points to that location (each dev has source checked out to a different location, this solves that)
Add the tag to the project as follows:
This works great, but VS complains that the file is unsafe, and I know to fix that we have to mark is safe in the registry. We wanted to create a .reg file to import this setting and make it easier for everyone. Can we use that environment variable in the path? I have tried the snippet below, but that doesn't seem to work. Is the syntax for an environment variable different?
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\9.0\MSBuild\SafeImports]
"StyleCop.4.3"="%StyleCopLocation%\\Microsoft.StyleCop.Targets"
Why you need to host that Targets file in a global place? Everyone can install a copy of StyleCop.
If you in fact plan to share StyleCop settings, please configure the projects to use a project locally setting file (*.SourceAnalysis). You can check in this file along with your projects, and then everyone is in sync.