Pub: pass metadata environment variable to dart2js #829
Comments
|
<img src="https://avatars.githubusercontent.com/u/1343914?v=3" align="left" width="48" height="48"hspace="10"> Comment by sgjesse Removed Type-Defect label. |
DartBot
added
type-enhancement
|
<img src="https://avatars.githubusercontent.com/u/188?v=3" align="left" width="48" height="48"hspace="10"> Comment by nex3 If we do this, it should be namespaced (e.g. PUB_PACKAGE_VERSION). |
|
<img src="https://avatars.githubusercontent.com/u/46275?v=3" align="left" width="48" height="48"hspace="10"> Comment by munificent We'd want to scope it to the package too, since this is useful for libraries as well as applications. It would be nice if the environment stuff had some concept of scoping. |
|
<img src="https://avatars.githubusercontent.com/u/46275?v=3" align="left" width="48" height="48"hspace="10"> Comment by munificent Removed Priority-Unassigned label. |
|
<img src="https://avatars.githubusercontent.com/u/188?v=3" align="left" width="48" height="48"hspace="10"> Comment by nex3 We could also just make it explicit that the version is for the entrypoint package (PUB_ENTRYPOINT_VERSION). Another possibility is to leverage the "faux library" technology we'll be using for bartender to create a package metadata library that's properly scoped. |
|
<img src="https://avatars.githubusercontent.com/u/188?v=3" align="left" width="48" height="48"hspace="10"> Comment by nex3 Issue #848 has been merged into this issue. |
|
<img src="https://avatars.githubusercontent.com/u/188?v=3" align="left" width="48" height="48"hspace="10"> Comment by nex3 Since I merged issue #848 into this, I'm going to retarget it at passing in various sorts of metadata. Changed the title to: "Pub: pass metadata environment variable to dart2js". |
|
<img src="https://avatars.githubusercontent.com/u/46275?v=3" align="left" width="48" height="48"hspace="10"> Comment by munificent |
|
<img src="https://avatars.githubusercontent.com/u/188?v=3" align="left" width="48" height="48"hspace="10"> Comment by nex3 This isn't really the same thing as issue #798. That issue is about allowing the user to pass in configuration variables; this issue is about pub passing in its own variables to provide information that pub knows about to the program. Added Triaged label. |
|
<img src="https://avatars.githubusercontent.com/u/648527?v=3" align="left" width="48" height="48"hspace="10"> Comment by Fox32 My current workaround for this is to use a barback transfomer that modifies a template file. So I can also include Git revision and build time. |
|
<img src="https://avatars.githubusercontent.com/u/46275?v=3" align="left" width="48" height="48"hspace="10"> Comment by munificent
This actually sounds like a great use of a transformer to me. |
|
<img src="https://avatars.githubusercontent.com/u/648527?v=3" align="left" width="48" height="48"hspace="10"> Comment by Fox32 Attachments: |
|
<img src="https://avatars.githubusercontent.com/u/444270?v=3" align="left" width="48" height="48"hspace="10"> Comment by seaneagan It looks like that attached transformer depends on the working directory being the root of the package in which the asset exists. Is that something we can depend on? |
|
<img src="https://avatars.githubusercontent.com/u/188?v=3" align="left" width="48" height="48"hspace="10"> Comment by nex3
It doesn't sound like this guarantee will work if it's used in a dependency. Barback certainly provides no guarantees about the working directory. |
|
<img src="https://avatars.githubusercontent.com/u/444270?v=3" align="left" width="48" height="48"hspace="10"> Comment by seaneagan What about exposing the package metadata at build time via the barback API? Then the community can write transformers to make package metadata available at runtime in the best way they see fit. Guessing there would be a |
|
<img src="https://avatars.githubusercontent.com/u/444270?v=3" align="left" width="48" height="48"hspace="10"> Comment by seaneagan I guess more likely it would be in the PackageProvider class, e.g.: Map<String, PackageMetadata> packageMetadata; (which might deprecate the existing Maybe expose the version as a Version (see issue #972) |
|
<img src="https://avatars.githubusercontent.com/u/188?v=3" align="left" width="48" height="48"hspace="10"> Comment by nex3 That's certainly something we're looking into. It would be nice not to force users to write a transformer if they just want to access this information programatically, though. |
|
<img src="https://avatars.githubusercontent.com/u/444270?v=3" align="left" width="48" height="48"hspace="10"> Comment by seaneagan A dedicated library or package would be the most convenient. I have another use case for such a thing as well, see issue #1154. |
matanlurey
added
the
closed-not-planned
|
We are no longer supporting transformers or We'll be updating the tooling section of the Dart website in the coming weeks with more formal documentation on how to get started. |
<img src="https://avatars.githubusercontent.com/u/648527?v=3" align="left" width="96" height="96"hspace="10"> Issue by Fox32
Originally opened as dart-lang/sdk#16370
It would be a nice to have if pub build/serve would pass the version (if it has one) of the current package (the package that is served, compiled) to dart2js as an environment variable (the new -D feature, e.g.: -DPACKAGE_VERSION=1.0.1+3).
That would allow developers to access the current version of their application via String.fromEnvironment('PACKAGE_VERSION'). There are many use cases, like displaying the current version in the application (to identify the versions on different environments) or including the version in error reports or ...
The text was updated successfully, but these errors were encountered: