rojo build should be able to update a place without nuking it

[vocksel]

Something I turn to Remodel for is management for all the assets I use in my game. This is both because Rojo does not allow me include my MeshParts in the project file (see #286), and also because rojo build nukes the given place file when building it.

I would prefer to have this managed by Rojo because it is already most of the way there for what I want, whereas with Remodel I have to independently manage lengthy import/export scripts.

It would be handy if Rojo had an option to "rebuild," an existing place, which would selectively nuke what the project has control over, but leave everything else in tact. For example, if the project managed a folder under ReplicatedStorage, it would nuke that folder when rebuilding, but it would not touch anything in Workspace.

[vocksel]

As an anecdote, my Remodel script to export assets from the game is 34 lines, however to recursively go over the hierarchy and import them back into the game is 213 lines. A good chunk of this is dealing with file paths.

Exporting I'm not too bothered by because Remodel makes it so easy, however the process of importing back into the game requires a lot of effort on the user's part, which I think could be handled more elegantly by Rojo.

[LPGhatguy]

This is an interesting feature idea, I've thought about a couple things in this space.

One idea would be to support a property on instances defined in a project that specifies that another thing should be merged in using a similar algorithm to the Rojo plugin.

{
  "name": "merging-place",
  "tree": {
    "$className": "DataModel",
    "$basedOn": ["MyPlace.rbxlx"],

    "ReplicatedStorage": {
      "$className": "ReplicatedStorage",

      "Game": {
        "$path": "src"
      }
    }
  }
}

With that idea in mind, this project would represent loading MyPlace.rbxlx and then merging in all of the instances defined in the project.

Some notes:

• This feature seems significantly less useful if we have good two-way sync.
• It's possible to have a feedback loop if we aren't careful because MyPlace.rbxlx is likely to contain instances defined in the project. I'd expect the consumer to build this project with rojo build -o MyPlace.rbxlx, which trivially makes Rojo affect itself!
• Disambiguating between "I want to add this instance" and "I want to merge this instance with the existing one" could be difficult, especially with name collisions.