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

build_runner only works the first time for each output_file_name #90

Open
stefan-schweiger opened this issue Jul 20, 2022 · 4 comments
Open
Labels
bug Something isn't working

Comments

@stefan-schweiger
Copy link

Describe the bug
When I run flutter pub run build_runner build --delete-conflicting-outputs with the following build.yaml the first time it generates the correct translations.g.dart file. But when I run the command a second time it generates nothing (if you delete the file you won't get a new one). If I change the output_file to something else it works again for one time and breaks again afterwards.

targets:
  $default:
    builders:
      slang_build_runner:
        options:
          base_locale: en
          output_file_name: translations.g.dart

For the same reason flutter pub run build_runner watch --delete-conflicting-outputs also doesn't work for me.

Expected behavior
The file should be regenerated each time the command is run.

Additional context

dependencies:
  flutter:
    sdk: flutter
  flutter_localizations:
    sdk: flutter  
  intl: ^0.17.0
  slang: ^2.6.1
  slang_flutter: ^2.6.0

dev_dependencies:
  flutter_test:
    sdk: flutter

  build_runner: ^2.2.0
  slang_build_runner: ^2.6.0

Additional question
Why is the --delete-conflicting-outputs needed in the first place? Libs like auto_route and json_serializable don't seem to need the flag to work.

@stefan-schweiger stefan-schweiger added the bug Something isn't working label Jul 20, 2022
@stefan-schweiger
Copy link
Author

stefan-schweiger commented Jul 20, 2022

I just tried it without output_file_name and noticed I have the same issue there as well.

@stefan-schweiger stefan-schweiger changed the title build_runner with custom output_file_name only works first time build_runner only works the first time for each output_file_name Jul 20, 2022
@Tienisto
Copy link
Member

Tienisto commented Jul 24, 2022

Hi,
currently, this library generates the dart file only if input changes. That's why your issue should be minor.
I will investigate if there is a way to force a rebuild.
Other libraries have a 1:1 relationship between source and output. build_runner will notice right away when you delete one of the output files. slang however, does not tell build_runner what and where to build beforehand. That's why build_runner only watches the i18n files and the config to determine if slang should be run.

Actually, --delete-conflicting-outputs may not be needed anymore. I added this option a time ago when it was kind of buggy.

My recommendation is:
Run flutter pub run slang on your dev machine. This command is build.yaml compatible.
On your CI (if you have one), you can run flutter pub run build_runner build. If you start from a clean environment everytime (which should be the case in CI), then everything should be okay.

@AdamHavlicek
Copy link

@Tienisto this behavior should be mentioned in the docs or in FAQ at least, because the newcomers might wonder why build_runner does not output anything or why build_runner fails to generate files

@goiditdev
Copy link

I am observing the same issue. The expected behavior, particular when using flutter pub run build_runner watch --delete-conflicting-outputs would be that it picks up changes in the JSON file and runs the builder to reflect those changes into the dart file. However, that does not occur, which for newcomers is quite frustrating.
This also seems to conflict with @Tienisto 's earlier statement: "this library generates the dart file only if input changes". The input does change, but the output does not.
When I run dart run slang it does regenerate the output, which is an acceptable workaround...just quite counterintuitive to the build-runner watch.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants