feat: change the settings through a config.json file

[marcos-cereijo-pexip]

Closes #8

[Copilot]

Pull request overview

This PR moves the plugin's hardcoded set_clock payload into an external public/config.json file, so deployments can customize clock behavior without rebuilding. It also adds a guard intended to avoid overriding an already-configured clock and documents the new config schema.

Changes:

• Fetch config.json at runtime and use it as the set_clock payload, with a new Config TypeScript interface.
• Call get_clock first to check current state before issuing set_clock.
• Document the configuration schema in the README and add example public/config.json; minor tsconfig and vite.config cleanup.

Reviewed changes

Copilot reviewed 5 out of 6 changed files in this pull request and generated 5 comments.

Show a summary per file

File	Description
src/index.ts	Loads config.json, queries get_clock, conditionally posts set_clock with fetched config.
src/types.ts	New Config interface describing the clock configuration shape.
public/config.json	Default config (type: time, UTC suffix) shipped with the plugin.
README.md	Documents the new configuration file, fields, and example.
tsconfig.json	Switches moduleResolution to bundler and adds an include list.
vite.config.ts	Removes a large commented-out block from the manifest definition.

Comments suppressed due to low confidence (1)

src/types.ts:6

• The date field in Config is typed as the literal date format string ('dd/mm/yyyy' | 'mm/dd/yyyy'), which is descriptive but the name date suggests an actual date value rather than a format specifier. Consider renaming to dateFormat (or date_format if matching the backend) for clarity.

  date?: 'dd/mm/yyyy' | 'mm/dd/yyyy'

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 6 out of 7 changed files in this pull request and generated 6 comments.

Comments suppressed due to low confidence (1)

src/validateConfig.ts:71

• buildConfig includes optional fields whenever they're valid in isolation, regardless of whether they apply to the chosen type. For example, a config with type: "elapsed" plus a date field, or type: "time" plus a starting_value, will pass validation and these irrelevant fields will be forwarded in the payload to set_clock. Consider only including type-specific fields when they apply (e.g., starting_value only when type === 'remaining', date only when type === 'time'), and/or warning on unexpected fields, so the runtime payload matches the documented schema.

const buildConfig = (
  obj: Record<string, unknown>,
  type: Config['type']
): Config => ({
  type,
  ...(isValidStartingValue(obj.starting_value) && {
    starting_value: obj.starting_value
  }),
  ...(typeof obj.prefix === 'string' && { prefix: obj.prefix }),
  ...(typeof obj.suffix === 'string' && { suffix: obj.suffix }),
  ...(isValidDateFormat(obj.date) && { date: obj.date })
})

[Copilot]

Pull request overview

Copilot reviewed 6 out of 7 changed files in this pull request and generated 5 comments.

Comments suppressed due to low confidence (1)

src/validateConfig.ts:63

• When type is "time" and the user omits date, validation succeeds and buildConfig produces a payload with no date field. The previous hard-coded behavior always sent date: 'dd/mm/yyyy'. This is a silent behavior change that depends on whatever default the backend applies. Consider either making date required for type: 'time' or applying an explicit default in buildConfig so the behavior is predictable.

  if (
    type === 'time' &&
    obj.date !== undefined &&
    !isValidDateFormat(obj.date)
  ) {
    logError(`"date" must be one of ${VALID_DATE_FORMATS.join(', ')}`)
    return false
  }
  warnIgnoredFields(type, obj)
  return true