Fix handling objects with relative URL

[sij411]

Summary

Handle relative url by adding baseUrl

Related Issue

Reference the related issue(s) by number, e.g.:

• fixes Cannot handle objects with relative URL's #411

Changes

• Added baseUrl support to vocabulary classes: All generated ActivityPub vocabulary classes now
  accept and store a baseUrl parameter through their fromJsonLd() method options
• Fixed relative URL handling: Modified URL decoders in type.ts to properly resolve relative URLs
  (like /media/image.jpg) by concatenating them with the provided baseUrl
• Enhanced error handling: Instead of crashing with TypeError: Invalid URL, the system now
  gracefully handles relative URLs by either resolving them with a base URL or returning null when no
  base URL is provided.
• Added public baseUrl accessor: Generated classes now expose a baseUrl getter property allowing
  users to access the stored base URL (e.g. protected readonly _baseUrl?: URL)
• Updated method signatures: Extended all relevant method options interfaces across the codegen
  system to support the new baseUrl?: URL parameter
• Relaxed validation: Modified dataCheck functions to allow relative URLs to pass through validation
  instead of being rejected. "http://www.w3.org/2001/XMLSchema#anyURI", "fedify:url" in type.ts

Benefits

• Prevents federation crashes: Eliminates TypeError: Invalid URL when
  encountering relative URLs from ActivityPub servers, significantly improving
  fediverse interoperability
• Graceful error handling: Returns null for relative URLs without base URL
  instead of throwing errors, allowing applications to handle missing data
  appropriately
• Backward compatible: Existing code with absolute URLs continues working
  unchanged while adding new functionality through the public baseUrl property
  getter

Checklist

• Did you add a changelog entry to the CHANGES.md?
• Did you write some relevant docs about this change (if it's a new feature)?
• Did you write a regression test to reproduce the bug (if it's a bug fix)?
• Did you write some tests for this change (if it's a new feature)?
• Did you run deno task test-all on your machine?

Additional Notes

• Couldn't return null on property.ts so it still returns Invalid URL issue if user use .fromJsonLd() without baseUrl

TS2345 [ERROR]: Argument of type 'URL | null' is not assignable to parameter of type 'URL'.
  Type 'null' is not assignable to type 'URL'.
        v["@value"].startsWith("/")
        ^

[github-actions]

The docs for this pull request have been published:

https://98ee571f.fedify.pages.dev

[github-actions]

The latest push to this pull request has been published to JSR and npm as a pre-release:

Package	Version	JSR	npm
@fedify/fedify	1.9.0-pr.443.1682+0f07cf27	JSR	npm
@fedify/cli	1.9.0-pr.443.1682+0f07cf27	JSR
@fedify/amqp	1.9.0-pr.443.1682+0f07cf27	JSR	npm
@fedify/cfworkers	1.9.0-pr.443.1682+0f07cf27	JSR	npm
@fedify/denokv	1.9.0-pr.443.1682+0f07cf27	JSR
@fedify/elysia	1.9.0-pr.443.1682+0f07cf27		npm
@fedify/express	1.9.0-pr.443.1682+0f07cf27	JSR	npm
@fedify/h3	1.9.0-pr.443.1682+0f07cf27	JSR	npm
@fedify/hono	1.9.0-pr.443.1682+0f07cf27	JSR	npm
@fedify/nestjs	1.9.0-pr.443.1682+0f07cf27		npm
@fedify/next	1.9.0-pr.443.1682+0f07cf27		npm
@fedify/postgres	1.9.0-pr.443.1682+0f07cf27	JSR	npm
@fedify/redis	1.9.0-pr.443.1682+0f07cf27	JSR	npm
@fedify/sqlite	1.9.0-pr.443.1682+0f07cf27	JSR	npm
@fedify/sveltekit	1.9.0-pr.443.1682+0f07cf27	JSR	npm
@fedify/testing	1.9.0-pr.443.1682+0f07cf27	JSR	npm

[dahlia]

@sij411 I've made some refinements to your approach and added a new commit (85cf50d) to improve the baseUrl handling.

I removed the unnecessary baseUrl property storage from generated classes while maintaining the relative URL resolution functionality. The changes include removing the baseUrl property and getter from generated classes, removing the baseUrl option from constructors, updating URL decoders to use options?.baseUrl directly with optional chaining for safer access, and adding an explicit baseUrlVar parameter to scalar type decoders for better type safety.

This approach is more efficient because classes don't carry around baseUrl they may never use, relative URLs are resolved only during JSON-LD decoding when needed, the generated code is significantly cleaner and smaller, and it maintains the same functionality for handling relative URLs when baseUrl is provided to fromJsonLd().

The changes are now pushed to your branch and should address the issue more elegantly while keeping the codebase clean.