“Real world” JSON transformation using Node.js
Maintenance by design
There are many times when I see this type of question regarding maintainability of the code. The line between code maintenance and user friendly becomes blurred. This is most evident when the coder is also the end user, the interface UI is misunderstood by familiarity of use, it is of course the IDE. This may sound somewhat pedantic, but the mind set it helps introduce can go a long way into how you design your code.
Encapsulate the interface
In this example if we look at the task of maintenance as an end user task, we design the code with all the possible changes encapsulated in a simple structure that isolates the code from the user. (Users can't code so don't let them near it, especially those users than think they can code (I am my most difficult client))
If done well the maintenance is trivial and the meat of the logic safe from the corruption inevitable when the logic must be reacquired in some maybe distant future.
So we can create am object called rules. It is the interface (abstract representation of codes functionality), and as with all good UI it will require some help information in the form of comments (remember the interface is the IDE)
As I have little to no clue what the possible alterations may be I have had to guess, this interface may not be adaptable to your needs. It is an example only
const rules = {
    name: &quot;Outputs&quot;,     // name of transformed object
    typesName: &quot;types&quot;,  // name of type ids array eg {Outputs: types: [1,4,23] }
    itemsName: &quot;locs&quot;,   // name of items object in and out  eg {Outputs: locs: {} }
    keep: [&quot;contents&quot;, &quot;last_update&quot;, &quot;plan_id&quot;, &quot;type_id&quot;],  // List of properties 
                                                              // to keep per item
    itemName: &quot;loc_id&quot;,  // name of property to use as named item
    ids: [&quot;type_id&quot;],    // list of property names containing ids for the array of types
};

The code can then use this encapsulated information as input, doing its thing and spitting out the result. Many changes can be made by just changing some text and never going near the logic.
function transform(data, rules) {
    const items = {}, types = new Set();
    const addTypes = from =&gt; rules.ids.forEach(key =&gt; 
         from[key] !== undefined &amp;&amp; (types.add(from[key]));
    const addProps = from =&gt; rules.keep.reduce((obj, key) =&gt; 
         from[key] !== undefined ? (obj[key] = from[key], obj) : obj, {});
    const transformLoc = loc =&gt; {
        const lName = loc[rules.itemName];
        if (lName !== undefined) {
            items[lName] = addProps(loc);
            if (loc.contents) { loc.contents.forEach(addTypes) }
            addTypes(loc);
        }
    }
    data[rules.itemsName].forEach(transformLoc);
    return {
        [rules.name]: {
            [rules.typesName]: [...types],
            [rules.itemsName]: items
        }
    };
}

const transformed = transform(data.Input, rules);

Even if we ignore this UI/code abstraction, the resulting code is more maintainable as you have moved many of the magic constants out of the code, and have been forced to think of what you are doing in a higher level abstract, that helps any future coders wrap their thinking nog around the logic.