We are looking to have the apiEndpoint in the sm.json file be one of 2 values depending on the branch. Is there any way to do this currently?
As a workaround, we are thinking we will remove the file from version control and generate it as a build step based on the environment variables.
Hi William,
Unfortunately, this is not possible at the moment and it's not currently being worked on. Although the team are open to the discussion around this.
How would you like this to work? Maybe replace sm.json with env variables?
Thanks.
Appreciate the quick reply - I waited too long to check on it!
Env vars would solve this, however, the simplest and most flexible approach might be to allow either a json or js file to be consumed by next-slicezone and the slicebuilder?
No worries. I've passed your feedback to the Slice Machine team. Hopefully, they'll get back to me soon with a response about this topic.
This is being tracked as an open feature request.
If you have another use-case for this feature, you can 'Flag' this topic to reopen. Please use the 
button to show your support for the feature and check out our Feature Request Guidelines.
This is something the team really wants to implement but it’s not in the pipe right now. If you have a certain scripted flow, you can rewrite the manifest whenever necessary of course.
Good to hear, Phil!
We were looking to use Slice Machine on our sites but not having this ability is a limitation for us.
The gist of our architecture is as follows:
We have two Prismic repos for two different sites. They're driven by the same codebase.
So one code repo, pulling from two prismic repos for content. The slices should all be the same regardless. We use two repos since the content is different and to improve editor organization.
Ultimately we would like to develop slices in slice machine and have them sync or pushed to both repositories in Prismic from one code repo.
If this is currently possible, please advise!
Thank you!
Hi Michael,
I agree this would be useful and this is a strong use case, but it's still not currently possible with Slice Machine.
So for the minute the case and workaround remain as above:
If/when this ever changes we'll update you here.
Thanks.
This would be a fantastic addition to Slice Machine (and probably a necessary one for large websites).
I don't really need to have shared custom types/slices between the repos, they can be completely separate entities.
The use case:
Of course, I can do everything in one repo, but that would be very messy.
I can initialise Prismic Clients for multiple repos, but how can I update Custom Types for individual repos (even more difficult now that I can't use the legacy custom type builder from within the writing room).
@Phil Is this currently possible in any way, even if it's a hack?
Hey @kris, We don't have an automated way to do this. We recommend you make a repo for each project in its entirety. Especially if it is independent pages. So you can have all the information in one place.
Hey @Pau - thanks for the reply.
Does that mean that the internal team doesn't have any plans to support multiple repos?
Even though Prismic is recommending to work from one repo, this is often unsustainable when growing your website and doesn't fit in every website's requirements.
A lot of developers need this feature and is currently supported if you are not using Slice Machine. For example, if you use the gatsby plugin - Connect to multiple Prismic repositories · Issue #145 · prismicio/prismic-gatsby · GitHub
We have had conversations about this, but we don't have anything planned. Sadly, we don't handle multiple endpoints, and you can't react to env variables in JSON. We still focus on 1 Prismic repo per project. But we do understand why it'll be helpful for some use cases.
A workaround could be to use @prismicio/client on its own for everything related to querying the API and having one instance of it per Prismic repository.
We can recommend you create something like a script at the root of your project and call it whenever it is necessary. For example, here's a simple "endpoint-switch.js" script that switches from one endpoint to another. The change should be reflected immediately in Slice Machine UI:
const fs = require("fs")
const manifest = require("./sm.json")
const endpoints = ["https://sm-env-example.prismic.io/api/v2", "https://endpoint2.prismic.io/api/v2"]
;(() => {
const index = endpoints.indexOf(manifest.apiEndpoint)
if (index !== -1) {
fs.writeFileSync(
"./sm.json",
JSON.stringify({
...manifest,
apiEndpoint: endpoints[1 - index]
}, null, 2)
)
}
})()
@Pau @prismicio/client can easily handle multiple repos so that's not the problem.
The endpoint-switch could work great, but the problem with this is how Slice Machine will handle the local files which are in the slices and .slicemachine folders - I don't think Slice machine will be able to differentiate they are they for different repos. But I might be wrong.
I highly encourage to continue this discussion internally and conduct user interviews to see what % of developers actually need this feature.
I appreciate that this feature will add architectural challenges in terms of implementation, but it would also add a lot of flexibility for the long term (and now will be definitely easier to add this compared to 2 years from now)
I understand, thanks a lot for your feedback.
Just wanted to flag a real life scenario where this is needed:
I'm currently in the process of planning a rebuild for my client's website. We will have the marketing website on one repo (it will use Slice Machine now as opposed to the current deprecated setup) but we would also like to migrate the support pages from Intercom over to an inhouse solution (using Prismic). Several reasons why we don't want to be on the same repo
I absolutely share Kristyan's opinion.
I'm currently building a "clone" from a four-year-old Prismic-based site. I'm using the same codebase for a completely independent client and project (my setup is pretty equal to Michael's outline. And of course the original project was built using the legacy builder. So for the moment I decided to use the legacy builder for the new repository too.
Form the "one codebase, many content repositories" perspective, slicemachine feels like a downgrade to me – at least for now. I'm a huge Prismic fan for years and I really hope to see an option to use slicemachine in the future for this kind of project setup.