Automatically `part` or `import` generated files

[davidmorgan]

Needs a language change :)

[lrhn]

Has been asked for before, and rejected. Not saying not to try, you may have better arguments and ideas, but it's worth checking what have been tried so far (it's mostly "allow importing *.dart or directories", but a few are more ambituous):

• Proposal: Import path mapping language#1424
• Why do we need to import an augmentation if the augmentation refers to the augmented library? language#1958
• Allow import of directories language#1969
• Can part directives be improved language#2287
• Glob or RegExp import/export language#1709
• Allow import and part to have wildcard path to import every lib in specific directory language#3915
• Omit part 'file.g.dart'; When defined in build.yaml sdk#60016
• Wildcard Exports – Because Typing Every File Name is for Cavemen sdk#60347

[Wdestroier]

A few reasons to support getting rid of part somehow:

• Java, C#, Python and other languages don't have this declaration.
• Writing this declaration in every file is a bad development experience.

[davidmorgan]

@lrhn Thanks! Indeed, not an easy one :)

It might be helpful to consider this in combination with #4085.

If there is a convenient way to hide most generated source, it doesn't matter how many we have, and maybe we just always generate one that pulls in all the others for you.

// hand-written foo.dart
part `foo.generated_parts.dart`; <-- the tools add this line for you if it's needed, and remove it if it isn't

// foo.generated_parts.dart, generated outside your source tree, as are the others below
part `foo.built_value.dart`;
part `foo.freezed.dart`;
part `foo.json_serializable.dart`

We can do other "auto part" features there, too. We can't auto import things for you though. Maybe that's fine, probably all generators end up writing enhanced parts and none need to be imports after that?

We could also consider if we can do any better if all the generated source ends up in one file, i.e. a source archive. Source archive with manifest? Hmmmmmmmm. Probably not.

[jodinathan]

Given that we know the part files are generated by a builder, we could introduce an intermediate part file that groups and describes the source-generated parts.

For example, imagine this syntax in the user’s source file:

// imports section

allow generated parts;

@Bar()
class Foo extends _$Foo {}

Here, allow generated parts; would act as syntactic sugar for something like part 'my_file.sdk.dart';. That intermediate file would then provide a condensed list of all generated part files along with metadata about them:

my_file.sdk.dart:

part of 'my_file.dart';

// generated by package:bar, builder BarBuilder
part 'my_file.g.dart';

my_file.g.dart:

part of 'my_file.sdk.dart';

class _$Foo {}

The idea is that cmd+click on allow generated parts; in an IDE would navigate to the generated summary file (my_file.sdk.dart), while hovering could show a popup with details about which builders produced which parts.

[mateusfccp]

@davidmorgan I think so.

The arguments provided in the issue I opened (#195), when I proposed that only the augmented file should have to annotate the augmented library, were related to the cost of having to scan for files and check their relations, or something like that, which is something solved by having both part and part of (or, in the context of augmentations, import <augmentation> and library augment <augmented>).

If all generated files were bundled in a structured way, dealt by the tooling itself, we wouldn't have this problem, as we would always know where the generated files were.

I'm not sure if this would required a change in the language or only in the tooling.

[davidmorgan]

Another direction we could go with this would be to do #4002, provide a workflow for builders to modify your checked-in source.

If builders can modify source in a low friction way, they can just add the part statement(s) for you as soon as they are needed. We need to be careful not to step on manual edits, but I think there can be a mode where edits from builders are pretty much immediately applied.

#4002 comes with a lot of other interesting use cases, but adding part statements is a nice one to start with since it applies to a lot of builders :)