We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
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
As of today each transpiled file as a library statement. The library name is unique and is derived from the file name.
library
Dart support private members (& functions & variables). Private members start with a "_" prefix.
A private member (/ function / variable) is visible to the entire library (whether it is accessed from the same class or file).
Currently dartanalyzer prints some warnings because "_" prefixed members are accessed from an other file (hence an other library).
dartanalyzer
What would be the right solution to support this:
@LIBRARY('name')
A short term solution could be to avoid "_" prefixed names but we should also have a longer term strategy IMO.
The text was updated successfully, but these errors were encountered:
This issue has been automatically locked due to inactivity. Please file a new issue if you are encountering a similar or related problem.
Read more about our automatic conversation locking policy.
This action has been performed automatically by a bot.
Sorry, something went wrong.
No branches or pull requests
As of today each transpiled file as a
library
statement. The library name is unique and is derived from the file name.Dart support private members (& functions & variables). Private members start with a "_" prefix.
A private member (/ function / variable) is visible to the entire library (whether it is accessed from the same class or file).
Currently
dartanalyzer
prints some warnings because "_" prefixed members are accessed from an other file (hence an other library).What would be the right solution to support this:
library
statement in the source code (may be via@LIBRARY('name')
if possible),A short term solution could be to avoid "_" prefixed names but we should also have a longer term strategy IMO.
The text was updated successfully, but these errors were encountered: