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

Could we put it in the SDK itself?

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.

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.

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.

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.

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.

Added Area-SDK, Triaged labels.

Issue #5355 has been merged into this issue.

cc @dgrove.

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

• Move dart.js from client/dart.js to pkg/client/lib/dart.js as a proper sdk-hosted pub package.
• In html files,
    replace: https://dart.googlecode.com/svn/branches/bleeding_edge/dart/client/dart.js
    with: packages/client/dart.js
• Require users to run pub for all examples, including ones that don't use pub today.

Pros:

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

Cons:

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

Thoughts?

cc @sigmundch.

To minimize the Cons, we can still allow people to replace:
  https://dart.googlecode.com/svn/branches/bleeding_edge/dart/client/dart.js
with:
  https://dart.googlecode.com/svn/branches/bleeding_edge/dart/pkg/client/lib/dart.js

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:

dartlang.org/dart.js

or

dartlang.org/dart-r15355.js

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

http://dart.googlecode.com/svn-history/r12148/trunk/dart/client/dart.js

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.

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

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

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

dependencies:
  client:
    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:

http://code.google.com/p/dart/source/list?path=/branches/bleeding_edge/dart/client/dart.js&start=15487

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

https://chromiumcodereview.appspot.com/11774006/

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
     https://dart.googlecode.com/svn/branches/bleeding_edge/dart/client/dart.js
      with
     https://dart.googlecode.com/svn/branches/bleeding_edge/dart/pkg/browser/lib/dart.js
2. Add the following to their pubspec.yaml:
     dependencies:
       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.

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.

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.

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.