importing private libaries during build_runner build

[codekeyz]

// This file has been generated by the reflectable package.
// https://github.com/dart-lang/reflectable.

import 'dart:core';
import 'dart:_http' as prefix8; // <---- why is it importing private libraries? 
import 'dart:async' as prefix9;
import 'package:pharaoh/src/http/request.dart' as prefix5;
import 'package:pharaoh/src/http/response.dart' as prefix6;

I am trying to use Cookie in a Class that is reflectable. I imported Cookie from

import 'dart:io' show Cookie;

And this is the error i get

test/router_test.reflectable.dart:5:8: Error: Can't access platform private library.
  import 'dart:_http' as prefix9;

[eernstg]

Thanks for the report, @codekeyz, that's useful to know!

The problem arises because Cookie is actually declared in a system library which is "private", and it is then imported by 'dart:io' and exported again from 'dart:io', which is the reason why we can get access to it at all in user code.

However, "private" libraries is not a Dart concept, that's a very special status which is given to a few system libraries. This is possible because the Dart tools (like the analyzer and the virtual machine) can "know" everything about the code which is part of the platform, and hence they can give special treatment to that kind of code.

This means that we can't really introduce a mechanism which is suitable for Dart code in general, and use that to resolve this issue. It will have to be special-cased in reflectable (which probably means that it isn't going to be maintenance-friendly).

Could you give some additional information about the usage of Cookie in your *.reflectable.dart library? Perhaps it's used in a constant expression, or as a type? If it is used in a way that is easy to avoid and not used for anything important then it might be possible to avoid the issue by a small adjustment of your program.

I'd like to have a more general solution, of course, but it isn't obvious how we could get a nice one. ;-)

[eernstg]

Of course, you can probably make it work by manually editing import 'dart:_http' as prefix8; to import 'dart:io' as prefix8;, or by removing that import entirely. If the latter works then Cookie isn't used after all, in which case there is a spurious import of an unused thing (which would also be a bug, so I'd like to know that, too).

[codekeyz]

I have an abstract class that is reflectable. say BaseHttpController. then i have another class UserController that extends the former.

@reflectable
abstract class BaseHTTPController {

   List<Cookie> get cookies => request.cookies ?? <Cookie>[];

}

Manually editing the generated files isn't an option as I'm purely using this in a Framework and that won't be anywhere close to being a neat/reliable fix.

Does this help in any way @eernstg

[eernstg]

Thanks, @codekeyz!

I was actually asking for usages of Cookie in the generated library, that is, the one that has the name n.reflectable.dart for some name n (that's often: main.reflectable.dart).

It is certainly possible to use a class like Cookie in a different library without needing an import of 'dart:_http' in the generated library. That's the reason why I'm asking about the generated library—the offending import isn't actually needed if the word Cookie isn't used in the generated code.

Manually editing the generated files isn't an option as I'm purely using this in a Framework

Of course! That wasn't a proposed solution or workaround, that was just an experiment that could be performed to narrow down the reasons why the failure occurs.

[eernstg]

This issue has remained open for a long time (mainly because I didn't have a way to reproduce the failure), but in the meantime it occurred to me that the situation around dart:_http is special: It is only imported by dart:io, which means that it is always safe to simply replace an import of dart:_http by an import of dart:io. This is not a general solution for the "importing an internal library" problem, but it should handle the case which is reported here.

#356 does this.

[eernstg]

@codekeyz, do you have an small example that gives rise to this error? The new code in the code generator needs to be matched up with a test, and the examples I've written don't give rise to the reported behavior (it doesn't try to import dart:_http).

[eernstg]

OK, the PR now contains an example that fails before the change and succeeds with the change.