Json_serializable.dart: Need to keep the generated code files into different folder or add the generated code to same model file.

[leen-nobbas]

I have 40 models, in my project. The Json serialisation really does have a lot of advantage.
It would be nice if we could keep the generated files in different directory, or the generated functions are kept in the same model file.

[denkuy]

I guess this is a limitation of the build system. The question is why are you asking for this. What is the problem?

[leen-nobbas]

Becuase we have like 40 models, and they are ever increasing. Now when we run the build command, we have like 80 files in the folder, it would be much better if we could store those files in some other folder.

[denkuy]

If it is about the number of additional files - you could use part and part of. That will create one g.dart file only (or however many files you join with part)

[leen-nobbas]

@denkuy I specified part 'generated.g.dart'; for all the models and tried to build it, but doesn't work. Am I missing something?

[denkuy]

What I mean is that you can, for example, have one file models.dart that will generate only one models.g.dart if you put part of “models.dart” in every single of your 40 model files. In models.dart you put all the imports and list all model files with part “something.dart”.
This has a few downsides, like you can only import all models at once & you have to specify all imports in models.dart

[leen-nobbas]

@denkuy That is an even messier approach, we did that with of our previous projects and its not a good practice. Models are better maintained when in their own files.

[denkuy]

I fail to see why this is messy or bad practice. If you use the part directives then the models __are__ in their own files, consider:

File models.dart

library models;

// add imports for all files
import 'dart:convert';

part 'models.g.dart'; // this contains all generated code for all models
part 'fancy_model.dart'; // "part" each model file
part 'not_so_fancy_model.dart';
// part '...';

file fancy_model.dart

part of 'models.dart';

@JsonSerializable()
class FancyModel {
    // your model contents
}

There are two limitations that come with this (maybe more)

1. you can not have import statements in the "part of"-model files, you have to put them in the models.dart (_This is not a problem for me, because models only include base data types or other models defined in these files_)
2. You can only import _all_ models at once via import '....models.dart';, but that is probably negated by just using a import 'models.dart' show FancyModel;

[joshwritescode]

I'm using this package for the first time and I already want to put my generated files in a subfolder of my data directory because it's so cluttered with .g.dart files at this point. Went looking for a solution and Google brought me here.

I think simply being able to supply a custom output path for *.g.dart files would be enough (maybe this could be added to the build.yaml (least favorite idea, not very flexible), or be another optional named parameter in the JsonSerializable constructor of the class, or it could read from the part directive for the .g.dart file to determine the path and give a nice error message if it can't find the directive (my favorite idea so far) - there's many ways to accomplish this.

Placing all models inside the same scope as you suggest means all classes within that scope would have access to even the private variables/methods of the other classes since they all belong to the same scope at that point. While that 'feature' can be handy, it definitely breaks OOP principles so we try to avoid that approach as much as possible.

[kevmoo]

This is not specific to json_serialization, but is a more general feature of how our build system works.

@jakemac53 – we should really put this request in under build, right – or at least source_gen.

[jakemac53]

There is probably an existing issue there that covers this - some of the options described won't fit within the constraints of the build system though which must be able to determine all the possible output files ahead of time before running any Builder code.

[micimize]

If this is such an issue, a lot of editors let you hide patterns. Like vscode .vscode/settings.json:

{
    "files.exclude": {
        "**/*.g.dart": true
    }
}

git can do the same thing

[kevmoo]

This is driven by the design of build, not this package.

See https://github.com/dart-lang/build/issues/1689

[lukepighetti]

I'm going with @micimize solution for this, thank you!