Can the `manifest.json` file be named anything other than `manifest.json`?

[medium_jon]

We started our first UXP based Adobe InDesign plug-in after putting the finishing touches on the first release of a Photoshop plug-in.

We wanted to keep both plug-in’s files in the same folder in our repository so that we reuse lots of parts.

But ran into the difficulty that if we rename the manifest.json file to anything else, while it will allow you to 'Add Plug-in` with a renamed file, that plug-in won’t load.

Here’s the adding the renamed manifest file:

And then when loading the plug-in I get this:

I feel like something in that load mechanism must be hard coded to require manifest.json rather than the file that was pointed to when Adding the plug-in.

Any suggestions?

Obviously I can still share code between my two plug-ins, just have to include the alternate path, but the above feels like a bug in UDT or UXP to me.

[pklaschka]

It’s (currently) not possible to name the manifest.json any differently. This also makes sense given that the process loading the plugin has to look for a specific file as an entrypoint (which, in this case, happens to be the manifest.json file).

While it would theoretically be possible for this file name to get adjusted “during loading” by UDT, this would create quite a number of edge cases (e.g., if you had an “additional” manifest.json file that then gets overwritten, etc.), which is why I don’t necessarily think having that option would be the best idea.

So overall, I totally understand where you’re coming from, but I would consider this to be a bug. A feature request perhaps (but even then, as mentioned above, I’m not sure how this could best be handled in practice). Just like for example Node/npm has the package.json, it tends to (in my opinion) make sense to have at least the main entrypoint be hard-coded. So I wouldn’t expect Adobe to add this feature anytime soon, if at all => it’s probably best to (at least for now) use another code splitting approach.

PS: As a heads-up, I’m (no longer) an Adobe employee (even though my profile here still says I am), so the above is my personal opinion and not an answer by Adobe .

[medium_jon]

Thanks for the comments Zuri!

I appreciated all you did while you were with Adobe! Glad to have met you on some of the online events. Best of luck with your future endeavors.

jsw

[medium_jon]

Looking more at this, it appears that we’re going to need to use something else to share code between our Adobe Photoshop and Adobe InDesign plug-ins. Might be copying a folder between the packages or it might be webpack as it seems to offer some other advantages.

As it is, it looks like the UXP plug-in architecture can’t gather items outside of the folder containing the manifest.json file.

[pkrishna]

@medium_jon UXP plugins can access location outside of plugin’s manifest. You will have to set the localFileSystem permission to ‘fullAccess’ for that.

[medium_jon]

Okay, I’ll try that again. I have that access now, but perhaps last week when I was doing the initial experimenting I didn’t have it configured.

Thanks @pkrishna!

[medium_jon]

@pkrishna: Perhaps I’m doing something wrong. Here is the manifest as it exists currently:

{
“id”: “btc4AID”,
“name”: “BLOX Total CMS”,
“version”: “6.0.0”,
“main”: “idClient.html”,
“host”: [
{
“app”: “ID”,
“minVersion”: “18.5”
}
],
“manifestVersion”: 5,
“entrypoints”: [
{
“type”: “panel”,
“id”: “BLOX_Total_CMS”,
“icons”: [
{
“width”: 23,
“height”: 23,
“path”: “icons/dark.png”,
“scale”: [
1,
2
],
“theme”: [
“darkest”,
“dark”,
“medium”
]
},
{
“width”: 23,
“height”: 23,
“path”: “icons/light.png”,
“scale”: [
1,
2
],
“theme”: [
“lightest”,
“light”
]
}
],
“minimumSize”: {
“width”: 230,
“height”: 200
},
“maximumSize”: {
“width”: 2000,
“height”: 2000
},
“preferredDockedSize”: {
“width”: 300,
“height”: 300
},
“preferredFloatingSize”: {
“width”: 300,
“height”: 300
}
}
],
“icons”: [
{
“width”: 48,
“height”: 48,
“path”: “icons/icon-48x48.png”,
“scale”: [
1,
2
],
“theme”: [
“darkest”,
“dark”,
“medium”,
“lightest”,
“light”,
“all”
],
“species”: [
“pluginList”
]
}
],
“requiredPermissions”: {
“clipboard”: “readAndWrite”,
“launchProcess”: {
“schemes”: [
“https”,
“http”
]
},
“localFileSystem”: “fullAccess”,
“network”: {
“domains”: [
“https://.bloxcms.com",
"https://bloximages..vip.townnews.com”,
“https://.townnews.com"
]
},
“webview”: {
“allow”: “yes”,
“domains”: [
"https://.bloxcms.com”,
“https://.townnews.com",
"https://.leeent.net”,
“https://admin.dev1.vip.inn.mwn.leeent.net”
]
}
}
}

(mercy that doesn’t post nice-sorry)

And then in the .html file it specifies I have this head:

<head>
<link rel="stylesheet" href="../psClient.css" />
<meta charset="UTF-8" />
<script src="idClientMain.js"></script>
<title>UXP Client</title>
</head>

Both I and VS Code see the psClient.css file in that ".//psClient.css" directory.

And here is an image of the directory structure with the html and the desired css file:

But UDT 1.9 shows this error:
​ Uncaught Error: Error: Failed to load CSS file: ../psClient.css Failed to invoke the stat. File Path: /Users/jwinters/uxp-client/uxp/UXP_client/btc4AID/psClient.css
or with more detail, this image:

So,:
a) do I have the permission option stated incorrectly in the manifest?
b) do have the path in the HTML incorrect?
c) or, is UDT unable to see outside the root folder of it’s manifest file?

Hopefully I just have something wrong. Would really like to share the CSS file directly.

[pkrishna]

I may have misunderstood your question. For including/managing css in your plugin you dont need to alter the manifest permissions.

It looks like the btc4AID does not have the psClient.css file indeed (as indicated by the error message) Can you update the href path in btc4AID/idClient.html to “…/…/psClient.css” and try once?

[medium_jon]

Yeah, @pkrishna, I had wondered as well if it was actually two folders up! Thus, I had already tried that. UDT still showed the similar error from that attempt:

​ Uncaught Error: Error: Failed to load CSS file: …/…/psClient.css
Failed to invoke the stat. File Path: /Users/jwinters/uxp-client/uxp/UXP_client/btc4AID/psClient.css

and is otherwise the same.

[pkrishna]

Does placing the psClient.css directly under btc4AID work?
Is btc4AID a build folder that is accidentally getting overwritten every time you build your project?

[medium_jon]

Alas @pkrishna, we aren’t, yet, using anything like webpack to build the plug-in. Though we likely will at some point in the future.

So currently, the head of the .html mentioned earlier file has this:
<link rel="stylesheet" href="./idClient.css" />

and from the earlier screen dump repeated here:

The idClient.css file is indeed in the btc4AID folder. And that .css file is just a renamed copy of the psClient.css file.

That local to the manifest one loads fine, no errors, the styles render, etc.

Does that answer your question? It’s not exactly what you asked, but I think it provides the same information.

[pkrishna]

I tried a few options but looks like the folder of the manifest is considered to be the root of your project. Referencing files outside of root, unfortunately, is not allowed.

I would advise you to use a project bundle, like webpack, to copy the common files into app-specific-plugin folders to make this easier for you.

[medium_jon]

Thank you again @pkrishna for looking at this again. I appreciate the time.

You came to the same conclusion that I had that there is currently no way for two+ plug-ins to natively share any common code because they can’t see outside their own root and you can’t share roots because UXP doesn’t allow the .json based manifest to be named uniquely for the project (though UDT certainly will). If the manifast.json could be uniquely named (say with the Adobe id for the plug-in) then code sharing becomes super simple.

Yes, we will likely switch to using webpack, or something similar, in the future. But I’d still like to see some ability to make this work for simpler plug-ins. For example we’re planning on making our current plug-in project available with unique feature sets for specific types of Adobe InDesign users at some of our 200+ locations. The code would likely be nearly identical but only certain parts of the user interface would be visible to the users based upon which plug-in they have installed (Page Designers, Ad Composition, Press Room, Template Masters, InCopy Editors, etc).

Jon