Skip to content
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

Native support for loading ES Modules #975

Closed
kitsonk opened this issue Oct 12, 2018 · 5 comments
Closed

Native support for loading ES Modules #975

kitsonk opened this issue Oct 12, 2018 · 5 comments

Comments

@kitsonk
Copy link
Contributor

kitsonk commented Oct 12, 2018

Currently Deno cannot load JavaScript that requires ES import statements natively. It supports it in TypeScript by transpiling the module to AMD and then loading it.

Both Node.js and d8 support this, so there are examples in place.

Adding this for tracking purposes as this is likely something I will work on in the future (e.g. this is fairly complex problem to tackle and not for the weak of heart).

@kitsonk
Copy link
Contributor Author

kitsonk commented Oct 23, 2018

Why did I think this was an issue? Mostly because I never tried it I guess. I just assumed that TypeScript wouldn't transpile JS files, but it does. So currently Deno will take something like this:

foo.js

import * as bar from "./bar.js";

(async () => {
  const baz = await import("./baz.ts");
  console.log(baz);
})();

export const foo = "bar";

console.log(bar);

And transform it to:

define(["require", "exports", "./bar.js"], function (require, exports, bar) {
    "use strict";
    Object.defineProperty(exports, "__esModule", { value: true });
    (async () => {
        const baz = await new Promise((resolve_1, reject_1) => { require(["./baz.ts"], resolve_1, reject_1);});
        console.log(baz);
    })();
    exports.foo = "bar";
    console.log(bar);
});
//# sourceMappingURL=data:application/json;base64,eyJ2ZXJzaW9uIjozLCJmaWxlIjoiZm9vLmpzIiwic291cmNlUm9vdCI6IiIsInNvdXJjZXMiOlsiZmlsZTovLy9Vc2Vycy9ra2VsbHkvZ2l0aHViL2Rlbm9fZXhhbXBsZS9zcmMvZm9vLmpzIl0sIm5hbWVzIjpbXSwibWFwcGluZ3MiOiI7OztJQUVBLENBQUMsS0FBSyxJQUFJLEVBQUU7UUFDVixNQUFNLEdBQUcsR0FBRyxzREFBYSxVQUFVLDJCQUFDLENBQUM7UUFDckMsT0FBTyxDQUFDLEdBQUcsQ0FBQyxHQUFHLENBQUMsQ0FBQztJQUNuQixDQUFDLENBQUMsRUFBRSxDQUFDO0lBRVEsUUFBQSxHQUFHLEdBQUcsS0FBSyxDQUFDO0lBRXpCLE9BQU8sQ0FBQyxHQUFHLENBQUMsR0FBRyxDQUFDLENBQUMiLCJzb3VyY2VzQ29udGVudCI6WyJpbXBvcnQgKiBhcyBiYXIgZnJvbSBcIi4vYmFyLmpzXCI7XG5cbihhc3luYyAoKSA9PiB7XG4gIGNvbnN0IGJheiA9IGF3YWl0IGltcG9ydChcIi4vYmF6LnRzXCIpO1xuICBjb25zb2xlLmxvZyhiYXopO1xufSkoKTtcblxuZXhwb3J0IGNvbnN0IGZvbyA9IFwiYmFyXCI7XG5cbmNvbnNvbGUubG9nKGJhcik7XG4iXX0=

Which loads perfectly with the Deno compiler and stack traces will map back to the source JavaScript file. I have an example available at kitsonk/deno_example.

So coupled with #1068 end users can fully author ES Modules in plain JavaScript, with type safety and even interpolate TypeScript and JavaScript modules. That significantly lowers the priority of this issue in my mind. There may be advantages to moving over to ES Modules from AMD, but the complication of integrating to V8 is rather daunting.

cc: @sebs

@sebs
Copy link

sebs commented Oct 24, 2018

Thanks for linking me ;) <3 Its a well received feature where I stand.

@ry
Copy link
Member

ry commented Dec 6, 2018

I’m working on this
WIP here https://github.com/ry/deno/tree/esm

@sebs
Copy link

sebs commented Dec 6, 2018

Ah, maybe a time to give my codebase a spin as I have some problems regarding esm (it was a esm test after all) .. Thanks. Building from source

ry added a commit to ry/deno that referenced this issue Jan 3, 2019
This reverts commit e976b3e.

There is nothing technically wrong with this commit, but it's adding
complexity to a big refactor (native ES modules denoland#975). Since it's not
necessary and simply a philosophical preference, I will revert for now
and try to bring it back later.
ry added a commit to ry/deno that referenced this issue Jan 3, 2019
This reverts commit e976b3e.

There is nothing technically wrong with this commit, but it's adding
complexity to a big refactor (native ES modules denoland#975). Since it's not
necessary and simply a philosophical preference, I will revert for now
and try to bring it back later.
ry added a commit to ry/deno that referenced this issue Jan 4, 2019
This reverts commit e976b3e.

There is nothing technically wrong with this commit, but it's adding
complexity to a big refactor (native ES modules denoland#975). Since it's not
necessary and simply a philosophical preference, I will revert for now
and try to bring it back later.
@ry ry mentioned this issue Jan 4, 2019
ry added a commit that referenced this issue Jan 4, 2019
This reverts commit e976b3e.

There is nothing technically wrong with this commit, but it's adding
complexity to a big refactor (native ES modules #975). Since it's not
necessary and simply a philosophical preference, I will revert for now
and try to bring it back later.
@ry ry mentioned this issue Jan 4, 2019
ry added a commit to ry/deno that referenced this issue Jan 7, 2019
This adds the ability to spawn additional Isolates from Rust and send
and receive messages from them. This is preliminary work to support
running the typescript compiler in a separate isolate and thus support
native ES modules (denoland#975).
ry added a commit to ry/deno that referenced this issue Jan 7, 2019
This adds the ability to spawn additional Isolates from Rust and send
and receive messages from them. This is preliminary work to support
running the typescript compiler in a separate isolate and thus support
native ES modules (denoland#975).
ry added a commit that referenced this issue Jan 8, 2019
This adds the ability to spawn additional Isolates from Rust and send
and receive messages from them. This is preliminary work to support
running the typescript compiler in a separate isolate and thus support
native ES modules. Ref #975.
@ry ry closed this as completed in #1460 Jan 9, 2019
@sebs
Copy link

sebs commented Jan 10, 2019

Thanks @ry ;) Big <3 for these changes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants