integrate with existing JS module systems #284
Comments
|
Regarding the browser, there are loaders like SystemJS that will convert ES6 modules to something else on the fly. The entrypoint output could set that up. |
|
I think it will be extremely useful to support such things as webpack-loaders. Which can help with incremental compilation and existing code integration.Is there any API to import existing es6 code from dart modules? |
yeah @jacob314 is working on something that will let you create a signature file for your JS code, then you can just call stuff in it. |
|
Closure's I've started toying with it in the closure-modules branch but we'll probably need to write more of the core runtime in Dart first (this could easily be done with a pass-through JS interop). |
yep.
hmmm, not sure we'd want "pass-through JS interop", as we're trying to move away from dart:js, which is only supported for backwards compatibility. We already have dart2js style edit: formatting |
|
@Aetet had a good comment on this:
|
|
I would vote for ES6 modules. They are the standard now so why support older module systems like CommonJS or AMD? From what I gather, if we could get standard ES6 modules as output we could easily make them work in the browser by either polyfilling the loading with SystemJS (as @justinfagnani pointed out) or just transform them with Webpack (as @Aetet pointed out). |
|
@jonaskello -- does any browser natively parse the ES6 module syntax? I don't think they do. So we can't generate raw ES6 modules and expect it to work in browsers. I don't want to force our users to run yet another transform tool before their code will work. The whole point of dev_compiler is to have a fast edit+refresh loop. Does node.js support ES6 modules? That would be a nice place to try them, if they work there. (I'm not sure.) Believe me, the moment we can drop legacy ES5 module stuff, we will! But that day has not arrived yet. |
|
AFAIK nodejs support ES6 modules under a flag, but I haven't tried it: node --v8-options | grep "in progress" Transforming ES6 to ES5 is already a well-solved problem in the JS world. Also hot-reloading is well-solved with webpack-loaders. Not sure of the value of solving them one more time in a Dart context. Although I do appreciate the effort to not introduce more tools. However my use-case is that I want to write libraries in Dart and consume in JS. With the output we get today that seems very difficult because I cannot plug that output into my JS toolchain (webpack, babel et al) because of the special module system used. I would rather have plain standard ES6 output, with standard ES6 modules (which is what I already use to write the JS application that would consume the Dart library) and just plug that output into my existing JS tool-chain. Would it be possible to add an option to dev_compiler so it either outputs its own module system, or plain ES6 modules? That way it would be possible to have a choice of either one-tool solution, or plugging into an existing JS tool-chain. |
|
Thinking more about it, I guess there are two use-cases for dev_compiler. Either you use it to build an app in Dart and iterate in the browser using dartdevc --server. In this case the one-tool solution is good. The other use case, which I think dev_compiler is meant to solve, is to write in Dart and consume from JS. Is there an issue discussing this latter workflow or should I create a new issue for that? (Rather than pollute this issue further :-)) |
|
@jonaskello, good points. A few thoughts:
|
|
I wanted to try to build a webpack loader that would (re)compile dart files using dartdevc and then chain that to the babel-loader. The goal would be to support a fast edit+refresh loop in any browser. But currently blocked on that dev_compiler output can not be compiled by babel because of a confirmed bug in babel. Not sure that it would work anyway but could be an interesting experiment. |
|
You could try renaming the local [https://github.com/dart-lang/dev_compiler/blob/master/tool/input_sdk/lib/async/stream.dart#L1215] and run: to avoid that particular case. But, it may occur elsewhere in the sdk. We try to preserve the original names whenever possible. |
|
I tried to run build_sdk.sh but I am not sure it is succeeding as it does not seem to update the files in lib/runtime/dart. I also get some severe errors in sdk_expected_errors.txt, not sure if that is related: |
|
Tried it some more times and now it actually worked. Must have gotten something wrong the first time around. Anyway, now I hit this error while compiling with babel. Not sure what to make of it, could be another babel bug?: |
That sounds like an internal error in Babel of some sort. If you could figure out what code it was trying to compile I might be able to guess what the issue is. @vsmenon wrote:
We could also just land a workaround for the SDK code, depending on how easy it is for Babel to fix. |
|
From the message it is not easy to know exactly what part of the code causes the babel error. If I get some spare time I could try to narrow it down somehow but meanwhile I created an issue over at the babel repo to see if they can help. UPDATE: I went to check on the babel issue, but seems they have migrated the issues to another site. Now it can be found here. Still no action on it though... |
|
@jmesserly After a lot of investigation I was finally able to come up with a minimal repro. Trying to compile the code below with babel will give the same error (this is code cut down from the 6000 lines in async.js though manual binary search :-)). Any ideas what it might be that babel has trouble with? It seems related to the name "value" because if I change to "value2" in one of the two places the error goes away. class Future {
wait() {
dcall(value);
}
}
class _Future {
[_asyncComplete](value) {
this[_zone].scheduleMicrotask(dart((() => {
_chainCoreFuture(this);
})));
}
} |
|
Hmmm. That seems to work in the REPL. Any idea what version of Babel that is? I'll see if I can reproduce it locally |
|
Interesting, maybe it works with 5.x then (it says the REPL is using 5.x). I am using the latest version (6.1.18). Here is what I am seeing: |
|
Seems to work:
|
|
Ah, maybe that's it. Can you try upgrading to babel-core 6.1.21 and see if it fixes for you? Not sure, but it looks like there were a bunch of recent fixes since .19: https://github.com/babel/babel/commits/master |
|
Upgraded but still same error (see below). However I am trying with my minimal repro file rather than the original async.js. I probably have a different async.js than you then, will check that.... If you try with the same content I have you probably get the same error? |
|
Your repro file works for me too, although it doesn't seem to transform anything. I guess you could try --no-babelrc. But the Babel folks might have some ideas, maybe ask on their issue tracker? |
|
Actually, in babel 6 it does not do anything by default (which babel 5 did). Which is probably why you are seeing the same output as input :-). See this page: https://babeljs.io/docs/setup/#babel_cli Specifically step 4 near the bottom of the page which states:
|
|
Seems you can also specify "presets" (which is what transforms it will make) on the command line if you don't want to create a .babelrc file. So if you run this we will probably get the same output: |
|
I filed #626 for requirejs support, so closing this one out. |
We have a few issues here:
<script>tags at runtime for everything else. (This pattern is fairly common, for example webcomponents.js)The text was updated successfully, but these errors were encountered: