Add support for syncing in a file as if it has a different extension

[Corecii]

Sometimes we have files that we'd like to include in Roblox, but they're either tool-generated with non-standard extensions, or they would work fine synced in as text. It would be nice to include these anyway by telling Rojo, "treat this as if it's a .xyz".

Examples:

• Wally generates a .lock file, which is really a toml. This could be synced in as text or as toml to ensure that the packages in the game match the lockfile.
• Git's files under .git are extensionless, but many are just text files. Some of these could be synced in to make sure the git branch matches the place (e.g. to ensure only main runs on production).
• Markdown files can be synced in as text files, while also maintaining editor support and without adding new extension handling code to Rojo.

[LPGhatguy]

Thank you for filing this issue! I think it's similar in spirit to #562 and #55, but I like how specific the examples you've presented are.

What do you think about overriding existing extensions? I like PRs like #633 in spirit, but I'm worried about potential compatibility hazards, especially when users are including Rojo projects written by different people.

Do you think that it'd be okay if these mappings only applied within a single Rojo project? This would help in case you depend on something like a Wally package that relies on toml files being turned into ModuleScript objects, but your project wants them as plaintext.

[Corecii]

Do you think that it'd be okay if these mappings only applied within a single Rojo project? This would help in case you depend on something like a Wally package that relies on toml files being turned into ModuleScript objects, but your project wants them as plaintext.

I think having this per-file or per-project is ideal. There are a few ways I imagined this working, and they're all scoped, not global:

• Per-file, where you can specify the type as .meta.json files or with meta config in the project file
• Per-directory, where certain extensions or certain filenames are rewritten
• Project-wide, where certain extensions or certain filenames are rewritten

For the actual use-cases I have for this feature, specifying one-off files in project.json is enough. From an end-user perspective, it would make sense to be able to include any file deep in the tree by using .meta.json, or to include a whole directory of e.g. .md files as plantext with a .meta.json on the directory.

I looked into adding support for using .meta.json to configure this, but .meta.json is only read after the filetype is determined. That could be worked around though if we decided that treating this like Rojo metadata makes sense!

---

I like PRs like #633 in spirit, but I'm worried about potential compatibility hazards, especially when users are including Rojo projects written by different people.

I wasn't worried about this specific case since .toml is not handled at all right now, so there's no backwards compatibility concerns. I don't think we should commit to plaintext-by-default (#562) because of forward compatibility concerns.

As long as the user is explicitly specifying the file type/extension override they want per-file, per-directory, or per-project, this should be forwards-compatible with any extension support added to Rojo. Since the user's config takes precedence, behavior of their project wouldn't change. Rewriting .newly_suported_ext -> .txt is analogous to rewriting .lua -> .txt, which should be fine too!

---

I think #55 can cover this, but I worry that implementing plugins will take a lot of time and work compared to adding native support for syncing in as a different extension.

[LPGhatguy]

I think one way we could implement this is as basically a watered-down version of plugins. What if we added a new property on project files that looked like this:

{
  "name": "example",
  "thingies": [
    {
      "pattern": "wally.lock",
      "use": "rojo/plaintext"
    },
    {
      "pattern": "**/*.md",
      "use": "rojo/plaintext"
    },
    {
      "pattern": "**/*.spec.lua",
      "use": "rojo/ignore"
    },
  ],
  "tree": {
    "$path": "src"
  }
}

I don't know what we'd call these thingies. The thing referred to by "use" would conceptually be a plugin, but we can just expose all the built-in Rojo transformers for now.

[Corecii]

That would work for my use-case!

[kennethloeffler]

This was closed by #813!