ballerina-spec icon indicating copy to clipboard operation
ballerina-spec copied to clipboard

Maintaining generated code in Ballerina package directory

Open sameerajayasoma opened this issue 2 years ago • 4 comments

We came across several cases where we wanted to make generated code part of the package source:

  • Generating such code inside the target directory is suboptimal, limiting us from committing the generated code.
  • Adding the generated code to package source directories is also problematic. Keeping them separate avoids accidental edits and has a clean separation from user-written and generated code.
  • A Ballerina package is a collection of modules. Default module sources are available in the package root directory, and other module sources are available in the modules directory.
  • Tools can generate a new module or add source files to an existing module.

I propose maintaining generated code inside the generated directory at the package's root. With this proposal, the directory name generated becomes a reserved directory.

  • The .bal files at the root of the generated directory become part of the package's default module.
  • Any direct subdirectory becomes a module in the package.
  • Those subdirectories will logically merge with existing modules in the modules directory.

I thought about having a generated directory in each module, but that doesn't work when adding new modules.

sameerajayasoma avatar Oct 17 '22 22:10 sameerajayasoma

So there's one more constraint:

  • None of the subdirs in generated can have the same name as subdir of modules/

I'm a bit uncomfortable with the idea of merging fines with the default module as that feels a bit kludgy as only the default module can be "patched" with generated code whereas others don't. Alternatively we can use the same semantic across the board: instead of saying the names of generated and hand-written modules can't overlap, we can say that if the names overlap the content merges.

sanjiva avatar Oct 18 '22 02:10 sanjiva

That's precisely the proposal, Sanjiva. I guess the original description wasn't clear.

  • Any direct subdirectory becomes a module in the package.
  • Those subdirectories will logically merge with existing modules in the modules directory.

I meant to say here that if directories named generated/foo and modules/foo exist in the package, then the module `foo' is created by merging sources in both directories.

sameerajayasoma avatar Oct 18 '22 03:10 sameerajayasoma

The generated sources will be picked when loading the project. This is with the assumption that no changes to the bal sources have been done after the last code generation (e.g. execution of bal persist command) and so the files under the generated directory are valid at the time of loading the package. WDYT?

Appreciate your opinion on the following as well.

  • By default should we add the generated directory to .gitignore?
  • In the lang server, should we open these files in the read-only mode?

Dilhasha avatar Nov 22 '22 11:11 Dilhasha

There can be VSCode code actions that update the generated code. E.g., we plan to have code actions to generate or update the generated code for changes in entity definitions. IIUC, the generated code can change even after loading the project, just like regular code.

Appreciate your opinion on the following as well.

  • By default should we add the generated directory to .gitignore? Yes.
  • In the lang server, should we open these files in the read-only mode? Yes.

sameerajayasoma avatar Nov 23 '22 03:11 sameerajayasoma

This capability is available in Ballerina now.

sameerajayasoma avatar Jul 15 '24 19:07 sameerajayasoma