Pub: pass metadata environment variable to dart2js

[DartBot]

This issue was originally filed by @Fox32

---

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 ...

[sgjesse]

Removed Type-Defect label.
Added Type-Enhancement, Area-Pub, Triaged labels.

[nex3]

If we do this, it should be namespaced (e.g. PUB_PACKAGE_VERSION).

[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.

[munificent]

Removed Priority-Unassigned label.
Added Priority-Medium label.

[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.

[nex3]

Issue #16613 has been merged into this issue.

[nex3]

Since I merged issue #16613 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".

[munificent]

Added Duplicate label.
Marked as being merged into #15806.

[nex3]

This isn't really the same thing as issue #15806. 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.
Marked as being merged into #.

[DartBot]

This comment was originally written 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.

[munificent]

My current workaround for this is to use a barback transfomer that modifies a template file.

This actually sounds like a great use of a transformer to me.

[DartBot]

This comment was originally written by @Fox32

---

Maybe someone is intereset my solution, so I attached it. A more general solution could be a canidate for a pub package. Thanks for @­kevmoo for making working with git easy.

---

Attachments:
package_info_transformer.dart (1.94 KB)
package_info.dart (363 Bytes)

[DartBot]

This comment was originally written 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?

[nex3]

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?

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.

[DartBot]

This comment was originally written 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 packageMetadata or similar field on AssetId.

[DartBot]

This comment was originally written by @seaneagan

---

I guess more likely it would be in the PackageProvider class, e.g.:

Map<String, PackageMetadata> packageMetadata;

(which might deprecate the existing packages field).

Maybe expose the version as a Version (see issue #18555)

[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.

[DartBot]

This comment was originally written 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 #21169.

[DartBot]

This issue has been moved to dart-lang/pub#829.