One of the big issues we still face is, because of how locked-down PackageLink instances are, it’s impossible to sync them externally through tools like Rojo.
Opening up the instance, giving us an API, and allowing us to set PackageId would be a great way to sync assets and ensure our relatively large development team (up to 70 in a single project) can get to work efficiently, and cooperatively.
hi @kingerman88 @metatablecatmaid we’ve definitely heard the pain of having to go publish each individual place to make package changes available in production. We’re brainstorming how we can improve this workflow without increasing the risk of unintended or untested changes making their way into live games. We’re still early in our thinking here, so feel free to DM me if you have any thoughts or feedback.
Auto-updates kick off when the place containing these packages are open (or opened) in Studio. It’s a useful feature for when there are many instances of the same object that you want to iterate quickly on altogether 
oh how i yearn for a CreatePackageLink method (because package links themselves should be read only imo)
hey @devSparkle I’d love to learn more about your external workflow here you’d like to have for packages. We’re working on an API for creation of packages, and we want to do more here - can you DM me so we can continue chatting more about your API needs?
Love this feature as a whole. Very helpful if you have scripts (usually modules) you want to use across multiple games without having to go through and update it in each one when you want to make a change.
Just hope this hasn’t caused the issue below and doesn’t have to be rolled back as a result, as the flag seems related 
:
This is cool, but I feel like what we really need is the ability to merge package updates and pending edits. If I add a script to a package, and then one of my coworkers publishes a change with a new part to it, I should be able to merge that without having to copy my script out, pull their change, put my script back in and publish. It should just pull the new part in. If there are conflicts on properties or whatnot, there should be a conflict resolution window (similar to the current diff window) that asks me what I want to keep. That is the final missing piece imo for packages.
Idk about the rest of the community but i feel the awkward truncating is really annoying so i made a poll
how do you feel about the truncating?
0 voters
Absolutely hate this change as I like to have the viewport be as big as possible.
It should be at least turned off as a default behavior (have a setting for it) or be removed entirely.
I myself was very confused as to why my explorer was behaving in the way pictured, and it made studio unpleasant to work with, I thought this was a bug.
HOW TO OVERRIDE
This behavior is triggered by the FFlag
ExplorerPackageIconColumn2. To override this I downloaded Roblox Studio Mod Manager, opened it and clicked theEdit Fast Flagsbutton, waited for it to download the files required for what it does, and then entered the FFlag in the search field, selected the FFlag and clicked Override.
After that, I launched it from the mod manager and that worked.
The updated icons look great! One complaint i have though is that they may easily be misunderstood, so I suggest adding some kind of alt-text to the icons when they are hovered over to make sure that they aren’t misunderstood.
The updates to the rest of the stuff looks fine.
So apparently this new update caused this weird truncation issue in the explorer.
As I understand it the truncation is there because of the new icons.
A simple solution to this would be to only truncate only if the icons are present on an instance and only the space the icons take up. I understand that this bug would go unnoticed in testing because of screen size but some people just still don’t have so many pixels to work with. I hope this gets fixed soon.
Please fix the truncation issue. It is severely disruptive.
They should add a sidebar, or remove this truncating it’s horrible
Last I checked the package state icons are 1:1 in size and do not need to take up the rest of the space in the explorer
If these icons are not user interactable then they should NOT be removing valuable information from the explorer, there is no need for this to happen and will actually teach people to NOT use this feature because how much of a PITA it is to use it on anything other than a 32 inch monitor.
Edit: Jesus christ I don’t have a single package in my game and this is still enforced???
Thanks so much for this fix, this works perfectly.
This truncation is too fat for some reason, and i hate it.
There’s one thing holding me back from implementing packages into my projects, and it’s that every single copy of a package has to be identical. Now this is useful for models that are used repetitively, such as trees in a forest, but they can’t be used for models that are similar but vary slightly. One example would be varying sizes of trees with varying shades of colour.
At the moment changing the name, position, rotation, and enabled properties (along with welds) don’t count as modifications. It would be nice if we could define what properties are and aren’t considered modifications for each packages. For the models below, the default excluded properties would apply, along with Color to allow different colours of the same model:
I am able to work great…!.. not…
Revert this. This is not “improved visibility”, but “reduced visibility”. Either there was a typo in the title or I have no idea.
Why do the icons need SO MUCH space?
Social distancing
Maybe its because they messed up the proportions?
Anyways:
Red: current border (wrong)
Green: intended border location
Blue: just make the icons’s background transparent lol.
my improved visibility:
