protos with no reboot logic/options in it still generates a rbt.js file

[katfang]

Describe the bug

If you have a proto file that doesn't have any reboot logic in it, it still generates an _rbt.js file, but doesn't have much interesting in it.

This is not so much "bug" as point of confusion.

To Reproduce
Steps to reproduce the behavior:

1. I had a giant cheaoss.proto file that I decided to split into smaller files (e.g. move.proto, piece.proto)
2. Some of those new smaller files don't have any reboot-ness to them (e.g. move.proto doesn't have any reboot state / methods)
3. in my cheaoss_servicer.ts file I changed from importing from .../cheaoss_rbt.js to .../piece_rbt.js and .../move_rbt.js
4. Since piece.proto has reboot logic, .../piece_rbt.js happily imported the moved messages.
5. move.proto, which has NO reboot logic, .../move_rbt.js got red squiggly lines. Changing this to import from .../move_pb.js worked just fine.
6. In addition, old *_rbt_react.js file remains even though that base .proto file no longer has reboot logic (and since it wasn't regenerated, tries to import a lot of things that don't exist anymore)

Expected behavior

I would expect either

1. For new .proto files, EITHER
2. the _rbt.js file doesn't get generated
3. the _rbt.js file still allows me to import the messages in that proto file.
4. for existing .proto files, if it longer contains reboot logic, the *_rbt_react.js gets deleted
5. leaving it hanging means there's a lot stuff that "looks like" it still exists to use in React, but actually, one layer down, it's trying to import things that no longer exist.

In this instance where I was splitting a larger proto file and therefore a larger _rbt.js file into smaller, slight preference for #2. In general, a little less clear to me what is preferable.

It looks like *_rbt_react.js only gets generated for files that have react-logic, so this should probably do the same.

Impact
How severely does this bug impact your use of Reboot?

• It's not having any negative impact
• It's annoying
• It's a serious problem
• It makes it impossible for me to use Reboot

Please explain why?

A new dev to protobufs / reboot wouldn't really understand what files are generated "for protobufs" vs "for reboot" and just knows "reboot is generating some files."

The fact that I can import the new partial _rbt.js same as the old larger _rbt.js implies to me that I will import the same messages, but it does not. If it didn't exist, I would have considered looking at the other file instead (which is named _pb.js which suggests it stores some protobuff-y stuff, so that's great!).

Client
Please complete the following information:

• Mac, VSCode 1.99.3

[rjhuijsman]

Thanks for the report!

Another datapoint: in Python we'll soon also generate ..._rbt.py files even when there's no Reboot annotations in the .proto file, because that's necessary for any "legacy"/"classic"/"plain" gRPC services in that file to be usable by a Reboot Application.

From that I conclude that we may also (sometimes) have to generate that _rbt.js file that caused confusion, so I think we should focus on avoiding the confusion by making every _rbt.js file just as useful as the target of an import as any other.

In addition, I agree that files that are no longer part of the generating set should be deleted to avoid confusion (and possibly errors?). Would it be a problem for you if that meant deleting the whole generated code's output directory?

[katfang]

Currently, my .proto files are stored in the same folder as the generated files, so, yeah, right now, if you blew everything away, that'd kinda be a problem. I don't think there's any particular reason why they need to be, though.

I got into this state by following the typescript quickstart, which has you
touch ./api/hello/v1/hello.proto

and then in the .rbtrc set:

protoc api/
protoc --nodejs=api/

If there's a better recommended, would love to hear it! (because, it takes me a hot second to locate the proto files in the pile of generated files when I want to edit them) (and also would love to have the quickstart updated)

[rjhuijsman]

Contrary to TS, the Python quickstart puts the .protos in api/ and its generated code in backend/api; there's tradeoffs with that though (e.g. for Python you have to carefully set the PYTHONPATH), so presumably something popped up in TS that made the shared layout seem like the better option - perhaps @rileysdev remembers what that was?

If you try the split layout in TS, do let us know how it goes!

[katfang]

tl;dr: It can be in a different directory, but any api/ folder you place could also hold non-reboot API stuff too (either your own public-facing API or interfacing with other APIs). Blowing away the whole output api/ folder seems dicey. Blowing away cheaoss/v1/ and rbt/ within the output folder seems okay. If you want to blow away the whole folder, probably the docs should carefully direct people to put in a reboot-specific api/ sub-folder (and even then, seems like someone could want their code structured in api/). I'm curious as to why not just delete known generated files (_rbt.ts, _rbt_react.ts, _pb.ts). ... Suppose then you have to keep track of them...

Details:

Made this diff:

 protoc api/
-protoc --nodejs=api/
-protoc --react=api/
+protoc --nodejs=backend/api/
+protoc --react=app/api/

Seems to work. It also generates the _pb files into the --react folder, so the react code can use the _pbs without reaching into the backend which is great!

Looking at these two (both ~2 years old), it seems that having api/ not in the app/ directory is slightly preferred.

Next.js seems to suggest that many things in the app/ directory are to mimic routing structure, though you can haveapp/api/ and not have it be routeable. Another potential location could be src/api/ instead of app/api/. (In fact, app/api looks like it potentially suggests this is your app's public facing API.)

So, short look over the literature suggests that the top level api/ directory is a reasonable-according-to-react/next place to shove the code, but it can be put elsewhere. But also given that structure, unless devs are led to put their code specifically in a reboot-generated directory of /api it seems a little dangerous to blow it all away. I wouldn't count on api/ (nor app/api nor src/api) being reboot only.

Generating the react code into backend/api/ also works just fine, but then you got imports in your frontend going to backend/api which just feels a little weird.

I do, however, love having the generated code in a separate folder from the .proto files and would love for the tutorial / docs to have this be a default.