Custom template in css extension is searched among CSS config dir instead of my extension config dir

[Chiyo-no-sake]

As the title states, I am writing an extension to store data of the CSS on OneDrive (each Pod has its OneDrive account linked).
I am pretty much done at it, but I still have one problem:

• When I run the community solid server from the directory of the extension package, everything works fine;
• When i install the extension in another package, and then run @solid/community-server with the configurations to use my extensions, my HTML templates are not found. Instead, they are searched in <npm package dir>/config/...., while they are, since the package is installed via npm, in <npm package dir>/node-modules/<extension-name>/config/....

The following are the steps I used to make it work (from the extension dir):

1. Created the extension package
2. Installed community-solid-server as an npm package
3. Start community-solid-server with my extension config

In the above way everything works fine, since templates are actually stoerd in the config dir on the package root directory. But I cannot ship my extension via repo so I would like to make an installable package.
In order to do this I've done the following:

1. Created the client package
2. Install community-solid-server
3. Install my extension
4. Start community-solid-server with custom config files

In this way, despite componentsjs works and all my extension's classes are up and running, the said html templates are not found since being searched in a supposed config dir in the root of the client package.

I had the same oucome also by installing both packages globally, then running css via npx.

It might be good to say also that my extension is not yet published to any registry, and the installation is done via filepath for now to it's package root (npm install [-g] ./extension/myextension), as I would like to do while developing it.

The following is how I reference the file from within the extension config for the view handler:

{
      "@id": "urn:css-onedrive-pods:handlers:OneDriveLoginViewHandler",
      "@type": "OneDriveLoginViewHandler",
      "comment": "A handler that provides a view for logging in to OneDrive.",
      "templates": [
        {
          "@id": "urn:css-onedrive-pods:default:OneDriveLoginHtml",
          "@type": "HtmlViewEntry",
          "filePath": "config/templates/onedrive-login.html.ejs",
          "route": {
            "@id": "urn:css-onedrive-pods:default:LoginOneDriveRoute"
          }
        }
      ],
      "index": {
        "@id": "urn:solid-server:default:IndexRoute"
      },
      "templateEngine": {
        "comment": "Renders the specific page and embeds it into the main HTML body.",
        "@type": "ChainedTemplateEngine",
        "renderedName": "htmlBody",
        "engines": [
          {
            "comment": "Will be called with specific templates to generate HTML snippets.",
            "@id": "urn:solid-server:default:TemplateEngine"
          },
          {
            "@id": "urn:solid-server:default:MainTemplateEngine"
          }
        ]
      },
      "...other"
    },

This is the package.json of the extension I am writing:

{
  "name": "css-onedrive-pods",
  "version": "0.0.1-alpha1",
  "description": "Extension of Community Solid Server that allows to create and manage pods on end-user OneDrive",
  "main": "dist/index.js",
  "types": "dist/index.d.ts",
  "scripts": {
    "test": "jest",
    "clean": "rm -rf .data",
    "start": "npm run build && community-solid-server",
    "start:seed": "npm run start -- --seedConfig ./seeded-pods.json",
    "build": "npm run build:ts && npm run build:components",
    "build:ts": "tsc",
    "build:components": "componentsjs-generator -s src -c dist/components -i .componentsignore -r css-onedrive-pods",
    "prepare": "npm run build"
  },
  "files": [
    "dist",
    "config"
  ],
  "keywords": [
    "solid",
    "pod",
    "onedrive",
    "onedrive-pod"
  ],
  "author": "Luca Pasini",
  "license": "ISC",
  "lsd:module": "https://linkedsoftwaredependencies.org/bundles/npm/css-onedrive-pods",
  "lsd:components": "dist/components/components.jsonld",
  "lsd:contexts": {
    "https://linkedsoftwaredependencies.org/bundles/npm/css-onedrive-pods/^0.0.0/components/context.jsonld": "dist/components/context.jsonld"
  },
  "lsd:importPaths": {
    "https://linkedsoftwaredependencies.org/bundles/npm/css-onedrive-pods/^0.0.0/components/": "dist/components/",
    "https://linkedsoftwaredependencies.org/bundles/npm/css-onedrive-pods/^0.0.0/config/": "config/",
    "https://linkedsoftwaredependencies.org/bundles/npm/css-onedrive-pods/^0.0.0/dist/": "dist/"
  },
  "dependencies": {
    "@solid/community-server": "^7.0.4",
    "class-transformer": "^0.5.1",
    "componentsjs": "^6.0.1",
    "nanoid": "^3.3.7",
    "node-fetch": "^3.3.2"
  },
  "devDependencies": {
    "@tsconfig/node20": "^20.1.2",
    "@types/jest": "^29.5.11",
    "@types/node-fetch": "^2.6.11",
    "componentsjs-generator": "^3.1.2",
    "dotenv": "^16.4.5",
    "jest": "^29.7.0",
    "ts-jest": "^29.1.1",
    "typescript": "^5.4.3"
  },
  "engines": {
    "npm": ">=10.0.0 <11.0.0",
    "node": ">=20.9.0 <21.0.0"
  }
}

[joachimvh]

Your HTML templates not being found is a consequence of how Node.js handles file paths. If you have a relative file path, such as config/templates/onedrive-login.html.ejs, it is interpreted starting from the location the Node.js process was executed, which is why you always want to work with absolute paths. With CSS we worked around that by creating a prefix @css: which the server interprets as the root path of the project:

CommunitySolidServer/src/util/PathUtil.ts

Lines 309 to 311 in f59b2c2

	if (path.startsWith(modulePathPlaceholder)) {
	return resolveModulePath(path.slice(modulePathPlaceholder.length));
	}

Since you can't use that prefix you should probably change your OneDriveLoginViewHandler so it interprets file paths relative to the root of that project folder.

I recently had the idea actually to allow new components to register their own prefix so the same utilities can be reused #1883.

[elf-pavlik]

Would each package of custom CSS components register its prefix, or would it happen where the final config is created, which uses core CSS and various components from multiple other packages extending CSS? If each package does it independently, it may be prone to collisions.

[joachimvh]

Neither. The idea would be to just provide a utility function that can be called to register a new prefix/path combination. This should then be called somewhere before doing any path manipulation.

[ksaito-hiu]

I am also creating an extension package and ran into the same issue. In my case, I created a subclass of the ejs template engine and used the override function in components.js to replace the CSS instances. Please refer to the TypeScript class and configuration file below.
https://github.com/ksaito-hiu/css-google-auth/blob/main/src/identity/interaction/google/temp/EjsTemplateEngineTemporary.ts
https://github.com/ksaito-hiu/css-google-auth/blob/main/config/identity/handler/routing/google/temporary.json
Sorry about that comments are wiritten in Japanese.
However, I am very hopeful that joachimvh's issue (#1883) will be implemented.