What’s the right way to resolve app.css and other non-registry files in jsrepo?

[mmailaender]

When I run jsrepo add routes/+layout it throws the error Invalid block! app.css/index does not exist!.

So the problem seems, that only convex, lib, and routes are included in the registry, but not app.css

It seems to me that jsrepo sees the import in import '../app.css'; and attempts to resolve it as the block app.css/index, but then fails when importing it. It also fails if the file already exists, so it seems the mechanic is only interested in whether the local import exists as a block or not.

These files are currently not covered by the registry, so adding them would simplify things significantly.

src/app.css
src/hooks.server.ts
src/app.html

I'm asking myself how to resolve this best. Any ideas?

Current jsrepo-build-config.json

{
	"$schema": "https://unpkg.com/jsrepo@2.4.5/schemas/registry-config.json",
	"name": "@auth/svelte",
	"version": "0.0.5",
	"readme": "README.md",
	"meta": {
		"author": "Micha Mailänder",
		"bugs": "https://github.com/mmailaender/auth/issues",
		"description": "Plug & Play Auth Widgets for your application",
		"homepage": "https://etesie.dev/docs/auth",
		"repository": "https://github.com/mmailaender/auth",
		"tags": ["auth", "svelte", "ui", "convex", "better-auth"]
	},
	"dirs": ["./src"],
	"allowSubdirectories": true,
	"doNotListBlocks": ["primitives", "_generated"],
	"doNotListCategories": [],
	"listBlocks": [],
	"listCategories": [],
	"excludeDeps": ["svelte", "@sveltejs/kit"],
	"peerDependencies": {
		"svelte": "5.x.x",
		"@sveltejs/kit": "2.x.x",
		"tailwindcss": "4.x.x"
	},
	"includeBlocks": [],
	"includeCategories": [],
	"excludeBlocks": [],
	"excludeCategories": [],
	"preview": false,
	"includeDocs": false,
	"rules": {
		"require-local-dependency-exists": "warn",
		"no-circular-dependency": "warn",
		"no-framework-dependency": "warn"
	}
}

[ieedan]

Normally you would add these as configFiles I can't remember if we actually resolve them as dependencies of blocks though...

[mmailaender]

Good hint. Added them as configFiles

"configFiles": [
		{
			"name": "app.css",
			"path": "./src/app.css",
			"expectedPath": "./src/app.css",
			"optional": false
		},
		{
			"name": "hooks.server.ts",
			"path": "./src/hooks.server.ts",
			"expectedPath": "./src/hooks.server.ts",
			"optional": false
		},
		{
			"name": "app.html",
			"path": "./src/app.html",
			"expectedPath": "./src/app.html",
			"optional": false
		}
	],

But now it's unhappy with my import in app.css

app.css ./src/app.css Config files cannot have local dependencies!

the app.css imports another css file (which is also a block)

@import './themes/auth.css';

Do you have any ideas for this as well? ;)

[mmailaender]

So you mean, a new feature? Is that a straight one? Should I create a PR, or do you have a solution already in mind?

[ieedan]

It's unfortunately not that straightforward will require a bit of thought. Ideally config files would only be able to depend on other config files. I suppose that may not be too hard to implement

[mmailaender]

To understand this a bit better: If I add a file to configFiles, does this mean that jsrepo will also ship that file to the user, or is it only ensuring via a check that the file exists?
Because if it's the first one, it would make a lot of sense to me that a local import in a config file could be part of another config file OR a block. However, that probably depends on the scope of the configuration files as well. If it's only about configuration files or, in general, about files that do not fit into the block structure (like in my case). 🤔

[ieedan]

Config files can be required or optional when initializing the registry if they aren't already being checked before adding blocks we should probably do that as well.

Ideally we would make it so that a config file that is required by a block must be required

[mmailaender]

Quick clarification about configFiles:

• When I run jsrepo init @auth/svelte / jsrepo add ..., are optional: false configFiles actually copied/scaffolded into the user’s project, or are they only validated for presence?
• If they’re shipped/copied, then it makes sense to me to scan their local @import/import statements and validate those dependencies exist as block or configFile (so the user ends up with equivalent content).
• If they’re not shipped (presence check only), then validating imports inside a config file feels odd—because the user’s local file might legitimately differ from the registry’s content.
  Could you confirm which behavior jsrepo implements today?