-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
need a story for dart.js offline -- perhaps via a pub package? #6723
Comments
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. |
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. |
Yup, they'll be developed in the main Dart svn repo, but not in the SDK. Users will get them from pub.dartlang.org.
Yup. Once we have a more stable versioning story in place, you shouldn't have to be so careful about this. |
Bob and I chatted offline about this. Here's a proposal:
Pros:
Cons:
Thoughts? cc @sigmundch. |
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: 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: 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: |
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:
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. |
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?
The text was updated successfully, but these errors were encountered: