Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

need a story for dart.js offline -- perhaps via a pub package? #6723

jmesserly opened this Issue Nov 14, 2012 · 19 comments


None yet
8 participants

jmesserly commented Nov 14, 2012

It is painful to load any Dart example offline, because the URL into SVN dart.js doesn't resolve.
One idea: a pub package, and I refer to it via <script src="../packages/loader/dart.js"></script>

It isn't perfect but it would be better than the current situation.

Pub guys/Vijay -- does this sound crazy? Better ideas?


munificent commented Nov 14, 2012

Not crazy. I've been burned by this too.

Could we put it in the SDK itself?


jmesserly commented Nov 15, 2012

Yeah, that would work. I noticed it's actually in the editor build under "samples/dart.js"

The problem is I don't know how to refer to it? Because I can't predict the relative path to the SDK.

We don't have a path we can use to get to the SDK location without some kind of symlink (or copy step).

cc @munificent.


vsmenon commented Nov 15, 2012

One advantage of putting into the SDK is that we occasionally having breaking changes (in the PortSync code) and it'd be best if dart.js was in sync with the SDK.

Can we use pub to pull packages from the SDK? I assume pub knows where the SDK is located?

cc @sethladd.
cc @devoncarew.


munificent commented Nov 15, 2012

We could make it an SDK package (like args, unittest, et. al.), I suppose, but we actually want to move away from that. If it is going to be a pub package, it should probably just be a regular one on pub.dartlang.org.


jmesserly commented Nov 15, 2012

Is the plan for Pub-SDK packages to publish them on the website (so they are hosted) but keep the source in the same location? So essentially we just need to make sure to upload them to pub around the same time as we push a new trunk build.


munificent commented Nov 15, 2012

Is the plan for Pub-SDK packages to publish them on the website (so they are hosted) but keep the source in the same location?

Yup, they'll be developed in the main Dart svn repo, but not in the SDK. Users will get them from pub.dartlang.org.

we just need to make sure to upload them to pub around the same time as we push a new trunk build.

Yup. Once we have a more stable versioning story in place, you shouldn't have to be so careful about this.


madsager commented Nov 15, 2012

Added Area-SDK, Triaged labels.


vsmenon commented Nov 30, 2012

Issue #5355 has been merged into this issue.

cc @dgrove.


vsmenon commented Nov 30, 2012

Bob and I chatted offline about this. Here's a proposal:


  • Fixes offline and startup time problems.
  • Fixes versioning issue I mentioned above: dart.js is guaranteed to match the sdk version.


  • Requires users to hardcode "package/..." path in their html - this has previously been an implementation detail.
  • Puts pub (and everything it depends on - e.g., dart:io) on the critical path to running anything.


cc @sigmundch.


sigmundch commented Nov 30, 2012

To minimize the Cons, we can still allow people to replace:

or - provide a permanent url for dart.js that is not directly pointing inside the source tree, instead it is a copy of the file that we push on every trunk release, for instance at:





dgrove commented Nov 30, 2012

We can serve up specific revisions directly from trunk. e.g.,



vsmenon commented Nov 30, 2012

Users will need to able to point to the latest dart.js - or, more specifically, the version matching the sdk they are using.

Using an sdk pub package will keep things in sync - better than today where their dart.js is newer than their sdk.


sethladd commented Dec 1, 2012

The editor now runs pub any time it senses a change to pubspec.yaml, so it's pretty transparent these days.


sethladd commented Dec 1, 2012

Oh, and we already have at least one formal sample that requires pub.


vsmenon commented Dec 7, 2012

I've experimented with this on github. If you add the following to your pubspec.yaml:

    git: git://github.com/vsmenon/client.git

Then, in your html, you can refer to it as:

<script src="packages/client/dart.js"></script>

I'd prefer moving this in the main repo under pkg, but we could mirror the file in github.com/dart-lang in the short term. There's a danger of getting out of sync, but it seems I'm the only one editing this file recently:



vsmenon commented Jan 8, 2013

I've created a CL based on comment 9 above (with 'client' -> 'browser').


I propose we land this and, once the corresponding editor update is published, we send out a breaking change notice to require people to either:

  1. Point to the new version directly by replacing
  2. Add the following to their pubspec.yaml:
        browser: any
      and use the appropriate relative URL in their html: "packages/browser/dart.js"

We'll delete the old dart.js afterward.

Set owner to @vsmenon.


sethladd commented Jan 8, 2013

yay for Vijay! :)

I don't want to recommend #­1. We should instead tell people to go to #­2, and give them a time frame, like 2 weeks, to update their code.

If we do #­1, we'll have to rip the bandaid off later when we move the packages out of pkg.


devoncarew commented Jan 8, 2013

I like having both options - both a stable URL and a pub package. For the very simple case, it's nice if your dart sample can run w/o having to first run pub. The editor does a good job of running pub now, but there are other tools out there. In any case, once this lands, we'll update the editor code and samples to use the new pub references to dart.js.


sethladd commented Jan 8, 2013

We don't run a CDN, and the best people to do that are the "make the web faster" team. They don't want to host anything unless it's stable. Until we hit a 1.0 I think we should only ship dart.js as a pub package. Once we hit 1.0 we can again ask the Make the Web Faster team to use their CDN.

This issue was closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment