Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Services with $path but not $className turn into folders #331

Closed
vocksel opened this issue Jun 20, 2020 · 6 comments
Closed

Services with $path but not $className turn into folders #331

vocksel opened this issue Jun 20, 2020 · 6 comments
Labels
type: enhancement Feature or improvement that should potentially happen

Comments

@vocksel
Copy link

vocksel commented Jun 20, 2020

I have partitions to ReplicatedStorage, ServerScriptService, and StarterPlayerScripts. I removed the $className field from all three. When running rojo build, ReplicatedStorage syncs normally, however ServerScriptService and StarterPlayerScripts both create new Folders instead of placing instances in the actual service.

@vocksel vocksel changed the title ServerScriptService still requires $className (6.0.0-rc.1) ServerScriptService and StarterPlayerScripts still requires $className (6.0.0-rc.1) Jun 20, 2020
@LPGhatguy
Copy link
Contributor

I'm not sure if this one is a bug or something we should document. I'm going to make a couple assumptions about how your project is structured; let me know if I'm wrong here!

Rojo always requires $className if it cannot intuit what the ClassName of an instance should be. One way that can happen is if your project node has $path defined. If $path is pointing to a folder, then the ClassName of the resulting instance will likely be Folder!

You should have a couple options to fix this:

  1. Keep using $className when you're also using $path
  2. Create init.meta.json files in the affected folders
  3. Move any project nodes that require $path one level down. Instead of specifying all of ServerScriptService via $path, just specify some subset of it.

@vocksel
Copy link
Author

vocksel commented Jun 21, 2020

You're exactly correct. Most of my partitions look like this:

"ServerScriptService": {
	"$className": "ServerScriptService",
	"$path": "src/server"
},

So when $className is removed, it's assuming Folder. The reason this didn't happen with ReplicatedStorage is because every project node is nested within a subfolder, just as you mentioned.

Definitely doesn't sound like a bug then, just something that could probably do with documentation

@LPGhatguy LPGhatguy added the scope: docs Docs need to be updated label Jun 21, 2020
@LPGhatguy LPGhatguy added this to the Rojo 6 Blockers milestone Jun 21, 2020
@LPGhatguy LPGhatguy changed the title ServerScriptService and StarterPlayerScripts still requires $className (6.0.0-rc.1) Services with $path but not $className turn into folders Nov 12, 2020
@LPGhatguy LPGhatguy added type: enhancement Feature or improvement that should potentially happen and removed scope: docs Docs need to be updated labels Nov 12, 2020
@LPGhatguy
Copy link
Contributor

After @nezuo's comment in #13, I'm wondering if this is something we should actually change instead of document. It's not likely that you want a Folder when you're in the same spot in the DOM as a service would be. We can probably loosen the logic here to overwrite Folder, or maybe overwrite Folder in certain circumstances?

@Bristlefrosts
Copy link

Bristlefrosts commented Apr 23, 2021

I'm having the exact same issue, except this time Rojo crashes with

[ERROR] Rojo crashed!
[ERROR] This is probably a Rojo bug.
[ERROR]
[ERROR] Please consider filing an issue: https://github.com/rojo-rbx/rojo/issues
[ERROR]
[ERROR] Details: If $className and $path are specified, $path must yield an instance of class Folder
[ERROR] in file src\snapshot_middleware\project.rs on line 101
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.

when trying to set $className to the correct service class name.

EDIT: Rojo 6.0.2 on Windows 10 Insider Preview 21364.1 (co_release)

@LPGhatguy
Copy link
Contributor

This is fixed up in master! We have much better error messages, and now this case is handled as expected.

@workframes
Copy link

I'm currently have the same issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: enhancement Feature or improvement that should potentially happen
Projects
None yet
Development

No branches or pull requests

4 participants