Release Notes

• Release Version: 3.0.0
• Release Date: Aug 1, 2025

Many things have changed dramatically and some will continue evolving... this is a simplified summary of things you need to know.

New Features and Changes

• Arranger is now just the ExpressJS server that used to be known as Arranger-API, which can still be integrated as a Router within your own server.
• All other parts of this monorepo are either Arranger's support libraries or client/consumers/extensions.
• We're slowly adding TypeScript support (e.g. type definitions in UI Components to facilitate integration, etc.). The migration from vanilla JS is still work in progress, and unfortunately that means the configuration schema is still a bit "in flux".
• We removed the ambiguous "Projects" (which were used to establish different configurations for a same "API"), and in their stead, Arranger now handles one index + mapping at a time. For "multi-index" functionality, integrators can implement multiple Routers within one same server of their own design.
• The implementation of the suite of UI Components for Arranger now follows a clearer separation of concerns paradigm, with a data querying layer distinct from their presentation and layout.
• Arranger also offers health and liveness endpoints now, useful for containerization and scalable cloud management.
• This release also addresses a plethora of documented bugs (and newly found ones too), too long to list here.

Full Changelog: v2.19.4...server-v3.0.0

Breaking Changes

As expected from most "major" version updates, there are quite a few things that may need attention:

• Mentioned above, Projects do not exist anymore as a form of establishing different configurations within a single Arranger. In order to set or change the settings for Arranger services, an integrator will have to modify the relevant configurations directly (as a file or group of them, with limited support through env vars for some values). There's also a new GraphQL query hasValidConfig, to verify whether Arranger is correctly configured to be used fro your needs.
• Furthermore, server/component configuration is now done through files (or JSON objects, possibly), rather than being hosted in Elasticsearch as a "projects" index. As a result, we have disabled the "admin-ui" that was used to update that index.
• Those configs also used to be included in the GraphQL requests as *State, and for clarity's sake, while still available they will now be nested inside a "configs" field, and grouped by Component family (e.g. configs > table > columns). We will document the new configuration schema more explicitly (and visually?) once the changes are finished.
• The relevant NPM packages are now published in the @overture-stack scope, to unify with the rest of Overture. Meaning the old @Arranger scope will only be kept of legacy support, but won't be updated any further.
• When trying to run Arranger in a NodeJS version older than v14, integrators will get error messages. This may require infrastructure updates for them (which is strongly encouraged anyway).
• The UI Components for Arranger will not work anymore in React versions older than 16.8 (because of Hooks). Though they should work correctly regardless of React version after that one, it is possible (though unlikely) some bugs may arise in React versions earlier than v17, but odds are your app already runs v18+ at this point. No "fixes" necessary in this case, as it is more of a "backwards support" kind of deal.
• While we fully migrate Arranger from Flow to TypeScript, it is possible (though unlikely, knock on wood) newly added type assertions could generate development/implementation errors in existing TypeScript apps. This is because we used to allow unintended usages that are now being avoided, or are "enforced" to be approached differently. This may require troubleshooting in a per-case basis if they ever come up, but that comes with the territory in a major release.
• All *State config data is now nested within the configs parameter, and aren't named "states" as they're to be considered static, per Server instance. The same data is also grouped as follows:
  configs > ( extended[] | facets > aggregations[] | table > columns[] | matchbox[] )
  This change was made bearing in mind upcoming customization capabilities for the facets panel, and foreseeing additional configs for other components that currently don't allow any customization, etc.
• The Table component doesn't include all the same "bells and whistles" out of the box anymore, and users must add the extensions separately (e.g. toolbar, pagination, etc.). i.e. all the relevant components are still provided, they're just separate items now.
• A few important properties have been renamed for clarity and or consistency:
  • Columns State's Table's defaultSorted is now defaultSorting.
  • Some instances of field are now found as fieldName, to help differentiate when you're dealing with the whole object vs only its name/identifier. This means there's no more field.field which was rather odd and confusing.

Migration paths

To be documented more clearly elsewhere, this is an overly simplistic list of steps to follow (meaning there are a few things that may be needed, yet not listed here):

Server

• Export the existing configs from a Project, using the "admin-ui" app. These files will come out named and we'll need to make a couple of changes before they can be used. (mostly removing clutter, and renaming a property or two for each field).
• Consolidate these along with a new base.json file (this name is not mandatory, but advised as documentation will refer to it that way) in a same folder. This new file will contain the document type (formerly known as "GraphQL field") to be used by Arranger Components when querying the Server, and the ES index name for the Server's own needs. Furthermore, the Server codebase includes a set of config templates that can be reused as reference.
• Back to the files exported from "admin-ui", they will contain JSON objects that need be modified slightly.
  • Each object needs to be nested within an object named after the function or component they serve (usually hinted at by their filename). e.g. extended.JSON is currently {[...]}, and with the mentioned nesting, becomes { "extended" : {[...]} }.
  • This schema file illustrates better the overall configuration schema expected by Arranger, which can be portioned into individual files, or presented all at once in a single JSON.
  • optional: If using a different folder from the one included in the codebase, give your path to the Server container as you run its Docker image using the CONFIG_PATH env var.
  • The error feedback from the server as it starts will be useful when trying to troubleshoot your configuration.

UI Components

Assuming Arranger (the Server) has been successfully migrated and running, which is necessary for the UI components' data-driven configuration, there are a few things to be aware of:

• If you're giving Arranger custom data fetching functions/middleware, remove any references to the admin and projects endpoints.
  i.e. both fantasticproject.com/admin/graphql and fantasticproject.com/<projectName>/graphql are now just fantasticproject.com/graphql unless you explicitly set it otherwise.
• Optional new feature You may make requests to the new hasValidConfig query. This helps verify the server has the right configs for a desired ES index and document type (aka "GraphQL field"), and to handle errors accordingly.
• In your existing v2.x compatible app, replace <Arranger /> with Arranger's new Data context <DataProvider/>, which is wired to add all the new providers necessary. Internally, the Arranger components that rely on this and other contexts already include their own hooks, etc; however, to facilitate creating your own Arranger consumer components, we expose useDataContext which allows access to Arranger's data and state management.
• Thought we tried our best to make a straight swap-out viable between those components, some setups may require a bit more intervention. i.e. The Data Provider only takes children, removing the component or render props, etc. For those cases, your components would only require adding the context injection hook mentioned before; removing the need for prop drilling adventures.
• (Renamed) CurrentSQON is now SQONViewer (changed for declarative semantics, and to avoid confusing the component with the variable for the state of the same name), and while the component with that original name is still available for integration, it will be deprecated in a later version. A console warning will be displayed when the old name is used.
• (Rewritten) There's a brand new Table, built upon the react-table v8 implementation (yes, already out of date, wow!). Its implementation is modular now (e.g. you can compose your own toolbar using individual sibling elements like pagination, total row counter, etc).
• We're also reducing the myriad of flag configuration props, so it's easier to reason with this set of components. Customization is now done through the theming system instead.
• TO DO: Detailed docs still need to be written in regards to the theming system itself. This is due to realizations made after its design, when implementing new visualization plugins we've been working on.

That's all. it's been a long time coming, but having a stable release will make new releases much faster and easier.
Reach out to us in whichever of the methods mentioned here suits your needs ...

Arranger Release Notes

• Release Version: 2.12.3
• Release Date: March 24, 2021

New Features and Changes

• Added support for a file manifest generation component - Component can generate a manifest file that users can download to use with Score. For now, the component uses fixed, default set of fields needed by Score (can't be dynamically changed). The component can be exposed in the web UI of a data portal running off the Arranger backend.
• Added support for accessing Arranger files & resources via sub-pathing in a proxy or gateway (e.g. /arranger/). This is required to support the DMS gateway routing requests to the correct service, as part of the Overture DMS platform bundle.