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

Meta issue for platforms specific tooling #33347

Open
2 of 4 tasks
leafpetersen opened this issue Jun 5, 2018 · 7 comments
Open
2 of 4 tasks

Meta issue for platforms specific tooling #33347

leafpetersen opened this issue Jun 5, 2018 · 7 comments
Assignees
Labels
area-language Dart language related items (some items might be better tracked at github.com/dart-lang/language).

Comments

@leafpetersen
Copy link
Member

leafpetersen commented Jun 5, 2018

This is the language meta issue tracking tooling support for platform specific compilation and analysis.

See #32960 for the background discussion.

Tracking issues:

@leafpetersen leafpetersen added the area-language Dart language related items (some items might be better tracked at github.com/dart-lang/language). label Jun 5, 2018
@leafpetersen leafpetersen self-assigned this Jun 5, 2018
@natebosch
Copy link
Member

Do we have an issue to specify the new format for config specific imports where only dart.library.* conditions are supported?

@jakemac53
Copy link
Contributor

jakemac53 commented Sep 5, 2018

@leafpetersen can you add an action item as @natebosch mentioned for fully specifying exactly what the syntax is and exactly what identifiers are supported? Is it all libraries present in libraries.json? If so then we also need flutter to ship with a valid libraries.json file and in a consistent place with the regular dart sdk.

For reference package:build just has a hardcoded notion of what is supported right now, which is derived from libraries.json and we made a best guess for flutter. Something more explicit would be great though, and the more restricted the set the better probably (but I mostly just care that it is explicit and documented).

@natebosch
Copy link
Member

In #34262 (comment) @lrhn indicates that the spec should not constrain it even if the tools do.

I think on another issue @matanlurey mentioned that if we're taking this approach we should consider adding a "tool spec" that indicates the subset of the language that the published SDK ships.

@matanlurey
Copy link
Contributor

+1 on tool specification. If say, Fuischa, wants to ship their own compiler that supports arbitrary conditional imports, go for it - but we should be clear the tools we provide (including the analyzer) do not.

@leafpetersen
Copy link
Member Author

Is a "tool spec" different from documentation?

What remains in question about the syntax?

@natebosch
Copy link
Member

Is a "tool spec" different from documentation?

It would be centralized.

@Levi-Lesches
Copy link

Hi -- what about dartdoc support? I recently found myself having to flip between misleading documentation and the corresponding files on github. Should I open an issue there? Judging by dart-lang/dartdoc#1980, it didn't seem like they have any plans to implement it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-language Dart language related items (some items might be better tracked at github.com/dart-lang/language).
Projects
None yet
Development

No branches or pull requests

5 participants