Giter Site home page Giter Site logo

Comments (8)

iapicca avatar iapicca commented on July 20, 2024 2

it would be nice to have a yaml file coverage_options.yaml
(like lints uses analysis_options.yaml)
or even better interact through pubspec.yaml
e.g.:

dev_dependencies:
  coverage: ^100.0.0

coverage:
  ignore:
    - '*.g.dart'
    - '*.pb.dart'

from coverage.

osa1 avatar osa1 commented on July 20, 2024 1

How widely use used is *.g.dart format for generated files? We don't use it in protoc_plugin, we use *.pb.dart.

I agree with @liamappelbe that whether I want to skip generated files or not depends on the use case.

  1. If I'm using a code generator (e.g. protoc_plugin) then I want to skip generated files. Testing of generated code should be done by the code generator.
  2. If I'm developing a code generator then I want coverage for generated files as well as I'm testing correctness of those in my package.

In general there will be more of (1) than (2) so ignoring generated files might make sense, but we should make sure code generators use a common suffix like .g.dart for generated files. Currently protoc_plugin does not do that (uses .pb.dart). If not then the default will be useless for some of (2) as well.

Either way we should have a flag for arbitrary globs.

If we ignore some files by default then the design of flags gets a bit more complicated as we will probably also need a flag to not ignore anything by default, or have a flag that is opposite of ignore-file (maybe allow-file).

If we don't ignore by default then one flag for ignoring files will do.

I say we don't ignore by default to keep things simple for now. If we want to ignore some files by default in the future it will be the same breaking change when we add it now.

from coverage.

devoncarew avatar devoncarew commented on July 20, 2024

I wonder if we should glob *.g.dart by default? Is there value in getting coverage info for generated code? Would excluding it by default be unexpected / surprising for users?

They would have the cli flag to disable the behavior if it was undesired.

from coverage.

liamappelbe avatar liamappelbe commented on July 20, 2024

I think I would find that surprising, if I was a user. In package:wasm I'd want to disable that behavior. I think the distinction is between users who have generated code that was generated by a 3rd party tool (eg protos), or generated by a tool that is part of the package (which is the case in package:wasm). The former case is probably more common, but in the latter case changing this default behavior would be a confusing breaking change.

As for whether we just add a flag to exclude *.g.dart, or add a flag that excludes arbitrary globs, I think it's probably going to be the same amount of work either way, so I'm inclined to just do the more general arbitrary glob approach.

from coverage.

natebosch avatar natebosch commented on July 20, 2024

I'm in favor of a flag which allows arbitrary globs.

from coverage.

devoncarew avatar devoncarew commented on July 20, 2024

How widely use used is *.g.dart format for generated files? We don't use it in protoc_plugin, we use *.pb.dart.

It's the main convention I believe. IIRC the analysis server relies on that file pattern to know to only report one issue for a missing import, instead of hundreds for the rest of the file (for type not found, ...).

If we had a default pattern here, I would default to that one.

Either way we should have a flag for arbitrary globs. I say we don't ignore by default to keep things simple for now. If we want to ignore some files by default in the future it will be the same breaking change when we add it now.

+1

from coverage.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.