About supporting a flat (gist like) structure to easily share dart snippets

[Kasper Peulen]

Hi all,

Some time ago I made this video about how to easily clone a dartpad in webstorm:

https://www.youtube.com/watch?v=AwUxnp5gv2g

Now dartpad stores their snippet as gist, and as gist allow only a flat project structure, every dartpad has a flat structure. With the following files: 

index.html, main.dart and styles.css.

Now the problem is that, pub doesn't really seem to support this structure. So if you are going to include packages, and transformers, things become a bit less easy then as this video suggests.

This is because `pub serve .` won't work. Webstorm does some magic however, at least in Webstorm 10, I could get any kind of snippet to work.

For example this angular 2 snippet:
https://gist.github.com/kasperpeulen/dd353c3d95b2da3dd74b

Webstorm seems to use `pub serve packages` in this case to serve the flat structure:

/usr/local/opt/dart/libexec/bin/pub serve packages --port=63372
Loading source assets...
Serving angular2.angular2_NgIf packages on http://localhost:63372
Build completed successfully
[packages] GET /angular2/src/reflection/reflection.dart => angular2.angular2_NgIf|packages/angular2/src/reflection/reflection.dart
[packages] GET /angular2/src/reflection/reflection_capabilities.dart => angular2.angular2_NgIf|packages/angular2/src/reflection/reflection_capabilities.dart
[packages] GET /angular2/angular2.dart => angular2.angular2_NgIf|packages/angular2/angular2.dart
[packages] GET /angular2/src/reflection/reflector.dart => angular2.angular2_NgIf|packages/angular2/src/reflection/reflector.dart
[packages] GET /angular2/src/reflection/types.dart => angular2.angular2_NgIf|packages/angular2/src/reflection/types.dart
[packages] GET /angular2/src/reflection/platform_reflection_capabilities.dart => angular2.angular2_NgIf|packages/angular2/src/reflection/platform_reflection_capabilities.dart

But now in Webstorm 11, this doesn't work, as there is no packages directory anymore.

I think it would be great if pub would support something like  `pub serve .` or maybe some convention like `pub serve dartpad` or `pub serve gist`.

This is just so that people can easily share code. So if someone at slack ask, "hi all, how I could I setup oauth2 github authencitation with only client side code in dart?" 

Then I can just share this gist: https://gist.github.com/kasperpeulen/ec3f3717f398ccce389e

Clone it in your editor, and it will run out of the box.

I'm trying to setup some kind of community driven dart cookbook, and this website also uses gists as backend with the same convention as dartpad (index.html/main.dart/styles.css). 

I want to make sure every snippet on this website pass the following quality standard: "every dartpad/gist will run directly out of the box in your editor." 

I can only make this promise, if dart allows to run a flat structure

[Bob Nystrom]

On Sun, Jul 26, 2015 at 8:22 AM, Kasper Peulen <kasper...@gmail.com> wrote:

Webstorm seems to use `pub serve packages` in this case to serve the flat structure:

Strange. I guess we never disallowed this in pub, but it was certainly never an intentional feature to be able to serve the "packages" directory on its own. That's... weird. But if it solves some problems for WebStorm, more power to them. :)

 

I think it would be great if pub would support something like  `pub serve .` or maybe some convention like `pub serve dartpad` or `pub serve gist`.

Pub historically didn't support .dart files at the top level of a package for complex historical reasons I won't get into. Now that we have the .packages file, I believe the constraints that led to that have gone away. (Actually, the change we did a long time ago to symlink directly to "lib" instead of the root directory may have removed this constraint.)

I think it would be possible now for us to support entrypoints at the top level of a package.

Note the emphasis on "entrypoints". What we would not support is a library in the top level of your package that you could import using a "package:" URL, since there is no "package:" URL that resolves to the top level of your package. But I think that would be fine.

Natalie may know of some other limitations I'm forgetting, but I think this is possible. It would make for a simpler layout for tiny packages, which would be great. Want to file a feature request?

Thanks!

- bob

[Kasper Peulen]

> Note the emphasis on "entrypoints". What we would not support is a library in the top level of your package that you could import using a "package:" URL, since there is no "package:" URL that resolves to the top level of your package. But I think that would be fine.

Makes sense. For my case, I would only need top level entrypoints to be supported.

> Natalie may know of some other limitations I'm forgetting, but I think this is possible. It would make for a simpler layout for tiny packages, which would be great. Want to file a feature request?

Sure. I will create an issue and try a PR. 

--
For other discussions, see https://groups.google.com/a/dartlang.org/
 
For HOWTO questions, visit http://stackoverflow.com/tags/dart
 
To file a bug report or feature request, go to http://www.dartbug.com/new

To unsubscribe from this group and stop receiving emails from it, send an email to misc+uns...@dartlang.org.

--

Kasper