I am building a Nuxt 3 SSR application, which I'm getting rather familiar with. What I can't wrap my head around, if it's even possible, is to have a single Nuxt project for multiple domains. For example, I have a few websites such as websitea.com, websiteb.com, websitec.com, and want to keep pages separate, while sharing components, compostables, etc. I'm not sure if this is possible, but it would be greatly appreciated if anyone has any advice.
I had this requirement too and came up with this solution:
Everything is shared as one Nuxt 3 app with a single nuxt.config.ts. The only difference is that each app has it's own sub-directory within /pages.
Here's how I set it up:
Create a pages structure like this:
/pages
--/website1
--/website2
--/website3
Define an env variable like WEBSITE_ID (e.g. within your project's .env)
WEBSITE_ID="website1"
Inside of nuxt.config.ts add this configuration:
export default defineNuxtConfig({
//...
dir: {
pages: `pages/${process.env.WEBSITE_ID}`
},
//...
})
When it's time to deploy your apps, inject the corresponding WEBSITE_ID env variable for each at build time.
While in development, simply edit the WEBSITE_ID within the .env to switch which website you're working on.
This setup makes it so that for example, when website1 is active, pages/website1 is treated as the /pages directory... so pages/website1/index.vue would be resolved when requesting /.
One of the solution would be to create a library using Nuxt Kit. This library will contain all of your components, composables and everything you need to share between your projects. You will need to add your library as a dependency of your different websites.
If you don't want to deal with multiple git repositories you can create a monorepo. (For example using pnpm: https://pnpm.io/fr/workspaces)
Related
In my Meteor 1.10.2 project, I have created a folder called assets inside the /public/ folder. When the Meteor application is built, I find this assets folder has been copied to these locations, as a direct child of the web.browser... folders:
/.meteor/local/build/programs/web.browser/assets/
/.meteor/local/build/programs/web.browser.legacy/assets
However, if I rename the folder to Assets (or if I give it any other name), when the application is built, I find it deeper in, inside the app folder at:
/.meteor/local/build/programs/web.browser/app/Assets/
/.meteor/local/build/programs/web.browser.legacy/app/Assets/
What is the logic behind this? What is the intention? What are the best practices for working with a folder at /public/assets/? Are there any other words that are given special treatment when used as names for folders inside the /public/ folder?
FWIW, this behaviour is specifically due to meteor tools bundler:
https://github.com/meteor/meteor/blob/release/METEOR%401.10.2/tools/isobuild/bundler.js#L719-L725
setTargetPathFromRelPath(relPath) {
// XXX hack
if (relPath.match(/^(packages|assets|dynamic)\//)) {
this.targetPath = relPath;
} else {
this.targetPath = files.pathJoin('app', relPath);
}
Therefore we can see that there are 3 special directory names that exhibit this special behaviour:
packages
assets
dynamic
Example with public assets:
These assets bundled in build:
For "packages", while we can understand that this is how Meteor ships the static assets of packages (i.e. when they call api.addAssets(), we can also see that there is a potential for collision, in the (however unlikely) case we use a pathname like "public/packages/my-package-name".
As for "assets", the initial name was "static", but I do not think it was publicly documented either.
And for "dynamic", I do not know yet what is its exact purpose, but we can see that it serves its content as "javascript" type (at least SVG files), whereas the first 2 serve them as "text/plain".
What Meteor does is build your project multiple times. Once for legacy web browsers, and again for a modern browser, and also for other platforms such as IOS or Android. It does all this inside the .meteor/local folder as you have observed.
Meteor has the concept of a /private folder, which is similar to /public, except that Meteor thinks of them as assets. This might explain why your folder appears in different locations, depending on the name.
Personally I wouldn't worry too much about how Meteor handles files, unless you want to become a contributor, in which case you are welcome to poke around :)
Per the Meteor docs, I'm trying to determine which special folder to place non-app assets (ex. Photoshop design PSDs) in, so that they still get checked into source control but don't get wrapped into the eventual client or server payloads.
It feels 'wrong' to use tests/ for this purpose but the docs suggest it has the desired behavior. Can private/ be used similarly, or will its contents always get added to the server bundle regardless of whether your app code registers any Assets? (Or is there a better place altogether to put such files?)
Consider a project structure like this:
/YourMeteorProject
/YourPSDFiles
file1.psd
file2.psd
...
/YourMeteorApp
/.meteor
/client
/server
...
You can launch your meteor app from within /YourMeteorApp. Files that are not part of your application, such as your PSD files, are kept outside of the application.
I made a simple REST API bundle with Symfony 2 and now i want to use ember.js as a client.
I made a new bundle for it (ClientBundle). Where should i put the js files? Into
the ClientBundle/Resources folder under public/js?
app/web under public folder
somewhere else
what is the best practice / your favourite folder structure?
The best practice is to put the client code into a separate repository and use JS specific tools for its development.
Just because you can put them into a single repository doesn't mean you should. Imagine what a mess that repository will become if/when you add other clients like Android, iOS, and so on.
We put the client JS under Bundle/Resources/public/ and have a separate frontend and backend bundle. We just published a sample distro to show how this is organized here:
https://github.com/ucsf-ckm/symfony-emberjs-edition
Currently the answer would be to store the assets in the /web directory. Source
If you intend the ClientBundle to be reusable across different projects you may have, you are best served by placing the files into the ClientBundle\Resources\public\js folder.
I am fighting with Xcode 4 workspaces. Currently Xcode 4 wins. Thus, my situation:
I have the workspace with the iOS app project. There is also static library project iOS app depends on in the this workspace.
Solution #1
I try to configure like this:
the app project:
add to target's Build Phases > Link Binary With Library a product (libmystaticlib.a);
set USER_HEADER_SEARCH_PATHS to $(TARGET_BUILD_DIR)/usr/local/include $(DSTROOT)/usr/local/include;
the static library project:
add some header files to target's Build Phases > Copy Headers > Public;
set SKIP_INSTALL to YES.
And important thing: both projects must have configurations named the same. Otherwise, if I have, e.g., configuration named Distribution (Ad Hoc) for the app and Release for the static library, Xcode can't link the app with the library.
With this configuration archiving results to an archive with the application and public headers from static library projects. Of course, I am not able to share *.ipa in this case. :(
Solution #2
I have also tried another configuration:
Xcode preferences:
set source tree for the static library, e.g, ADDITIONS_PROJECT;
the app project:
add to target's Build Phases > Link Binary With Library a product (libmystaticlib.a);
set USER_HEADER_SEARCH_PATHS to $(ADDITIONS_PROJECT)/**;
the static library project:
don't add any header files to Public!;
set SKIP_INSTALL to YES.
I still need to care about configuration names for both projects. But in result I can build and archive successfully. In the result I get archive and I can share *.ipa.
I don't like the second solutions, because in this case I don't get any real advantage of the Xcode 4 workspace. The same effect I can add get, if I add the static lib project inside the app project. Therefore, I think something is wrong with my solution.
Any suggestion how better to link a static libraries?
I also found a solution that works with build and with archive.
In your static library set the Public Headers Folder Path to ../../Headers/YourLib
In your app config set the Header Search Paths to $(BUILT_PRODUCTS_DIR)/../../Headers
In your app you will be able to code #import <YourLib/YourFile.h>
Don't forget the Skip Install = YES option in your static lib.
We've found an answer, finally. Well, kind of. The problem occurred because Xcode 4 places public headers into InstallationBuildProductsLocation folder during build for archive. Apparently, when archiving it sees the headers and tries to put them into archive as well. Changing Public Headers Folder Path of the lib to somewhere outside of InstallationBuildProductsLocation, for example, to $(DSTROOT)/../public_folders and adding this path to Header Search Path solve the problem.
This solution doesn't look very elegant, but for us it seems to be the only option. May be you'll find this useful.
Here is a solution a get from Apple DTS. I don't like it, because it is suggests to use absolute path. But I still publish it here, maybe someone feels it is right for him.
How to set up the static library:
Add a build configuration named "Archive" by copying the Release Configuration.
Move your headers to the Project group of the Copy Headers build phase.
Set the Per-configuration Build Products Path of the "Archive" configuration to $(BUILD_DIR)/MyLibBuildDir. Xcode will create the MyLibBuildDir folder inside the BuildProductsPath, then add your static library into that folder. You can use "MyLibBuildDir" or provide another name for the above folder.
Set Skip Install to YES for all configurations.
Set Installation Directory of "Archive" to $(TARGET_TEMP_DIR)/UninstalledProducts.
Edit its scheme, set the Build Configuration of its Archive action to "Archive."
How to set up the project linking against the library:
Add a build configuration named "Archive" by copying the Release Configuration.
Set the Library Search Paths of "Archive" to $(BUILD_DIR)/MyLibBuildDir.
Set the User Header Search Paths to the recursive absolute path of your root of your workspace directory for all configurations.
Set Always Search User Paths of "Archive" to YES.
Set Skip_Install to NO for all configurations.
Edit its scheme, set the Build Configuration of its Archive action to "Archive."
I was not real happy with any of the other solutions that were provided, so I found another solution that I prefer. Rather than having to use relevant paths to put the /usr/local/include folder outside of the installation directory, I added a pre-action to the Archive step in my scheme. In the pre-action I provided a script that removed the usr directory prior to archiving.
rm -r "$OBJROOT/ArchiveIntermediates/MyAppName/InstallationBuildProductsLocation/usr"
This removes the usr directory before archiving so that it does not end up in the bundle and cause Xcode to think it has multiple modules.
so far I also struggled with the same problem, but did come to a solution with a minimal tradeoff:
This requires Dervied Data to be your Build Location.
I set the Public Headers Folder path to ../usr/local/include
This will ensure, that the headers will not be placed into the archive.
For the app, I set the Header Search Path to:
$(OBJROOT)/usr/local/include
$(SYMROOT)/usr/local/include
There are 2 entries necessary since the paths slightly change when building an archive and I haven't figured out how to describe it with only one variable.
The nice thing here is, that it doesn't break code sense. So except for having 2 entries rather than one, this works perfectly fine.
I'm struggling with the same problem at the moment. I didn't progress much farther than you. I can only add that in the second solution you can drag headers you need to use from the library to the app project, instead of setting ADDITIONS_PROJECT and USER_HEADER_SEARCH_PATH. This will make them visible in app project. Value of SKIP_INSTALL flag doesn't matter in this case.
Still, this solution isn't going to work for me, because I'm moving rather big project, with dozens of libraries, from Xcode 3 to Xcode 4, and it means really a lot of drag and drop to make my project build and archive correctly. Please let us know if you find any better way out of this situation.
I could use Core Plot as a static library and workspace sibling, with two build configurations:
Release:
in project, Header Search Path: "$(BUILT_PRODUCTS_DIR)"
in CorePlot-CocoaTouch, Public Headers Folder Path: /usr/local/include
AdHoc (build configuration for "Archive" step in Scheme, produces a shareable .ipa):
in project, Header Search Path: "$(BUILT_PRODUCTS_DIR)"/../../public_folders/**
in CorePlot-CocoaTouch, Public Headers Folder Path: ../../public_folders
Hope it will help someone to not waste a day on this.
I would like to create an installer that installs 6 websites, all of which rely on a data access library. So the solution contains 6 web applications, and 1 class library.
Question is: how can I accomplish this without using custom actions?
So far, the only thing I've thought of is to make merge modules out of the web app projects, each of them throwing in the primary output of the class library project, and then making a main installer that has all the merge modules.
I would put each website in a feature that way you could give the end user the control over which website they require, if that is an option.
Although, you'll have to repeat the same type of code for each website in their respective.wxs file.