make @types/node an optional ranged peer dependency

XMLWordPrintableJSON

    • Type: Task
    • Resolution: Won't Do
    • Priority: Minor - P4
    • None
    • Affects Version/s: None
    • Component/s: Dependencies
    • Not Needed
    • None
    • Hide

      1. What would you like to communicate to the user about this feature?
      2. Would you like the user to see examples of the syntax and/or executable code and its output?
      3. Which versions of the driver/connector does this apply to?

      Show
      1. What would you like to communicate to the user about this feature? 2. Would you like the user to see examples of the syntax and/or executable code and its output? 3. Which versions of the driver/connector does this apply to?
    • None
    • None
    • None
    • None
    • None
    • None

      Use Case

      As a node driver user
      I want to know which versions of @types/node are driver-compatible
      So that I can develop without type regressions

      User Experience

      • The user should know which versions of @types/node are compatible with the node driver

      Dependencies

      • upstream and/or downstream requirements and timelines to bear in mind

      Risks/Unknowns

      • Open bugs which are sourced from type compat between node versions we intend to support may block the completion of this task

      Acceptance Criteria

      Implementation Requirements

      • @types/node should be changed to a peer dependency, the targeted version should be a range of versions we intend to support, e.g: `"^22.0.0 || ^24.0.0"`.
      • @types/node should be listed as an optional peer dependency

      Testing Requirements

      • Tests which rely on @types/node should be run in CI runs targeting all of the major versions of @types/node we intend to support

      Documentation Requirements

      • DOCSP ticket, API docs, etc

      Follow Up Requirements

      • additional tickets to file, required releases, etc
      • if node behavior differs/will differ from other drivers, confirm with dbx devs what standard to aim for and what plan, if any, exists to reconcile the diverging behavior moving forward

            Assignee:
            Unassigned
            Reporter:
            Johnathan Martell
            None
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved: