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

Experimental ES Modules (*.mjs) #1212

Closed
wants to merge 5 commits into
base: master
from

Conversation

Projects
None yet
2 participants
@DenisCarriere
Member

DenisCarriere commented Jan 5, 2018

Experimental ES Modules (*.mjs)

Using Node 9.3 you can use the new ES Modules (import & export) syntax by using --experimental-modules flag.

Downside is it's very strict on the file extension, it must be *.mjs.

Going to publish 3 main TurfJS core modules that experiment when importing it from different libraries, internally it seems to be fine, when publishing to npm it's a different story.

$ node --experimental-modules index.mjs

References

https://github.com/nodejs/node-eps/blob/master/002-es-modules.md#44-shipping-both-esm-and-cjs

4.4. Shipping both ESM and CJS

When a package.json main is encountered, file extension searches are used to provide a means to ship both ESM and CJS variants of packages. If we have two entry points index.mjs and index.js setting "main":"./index" in package.json will make Node pick up either, depending on what is supported.

4.4.1. Excluding main

Since main in package.json is entirely optional even inside of npm packages, some people may prefer to exclude main entirely in the case of using ./index as that is still in the Node module search algorithm.

DenisCarriere added some commits Jan 5, 2018

@rowanwins

This comment has been minimized.

Show comment
Hide comment
@rowanwins

rowanwins Jan 7, 2018

Member

Hey @DenisCarriere I was wondering just the other day if we were at a stage we're individual modules could be made available via a CDN, if I understand correctly that could be an outcome of this work?

Member

rowanwins commented Jan 7, 2018

Hey @DenisCarriere I was wondering just the other day if we were at a stage we're individual modules could be made available via a CDN, if I understand correctly that could be an outcome of this work?

@DenisCarriere

This comment has been minimized.

Show comment
Hide comment
@DenisCarriere

DenisCarriere Jan 7, 2018

Member

@rowanwins You should be able to use these now, I've published helpers, meta & invariant under the 6.0.0-beta.3 release.

You can do something like this with your HTML:

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <title>ES Modules - Single Module</title>
  </head>
  <body>
  <script type='module'>
    import {point} from "https://unpkg.com/@turf/helpers?module"
    console.log(point([100, 0]));
  </script>
  </body>
</html>
Member

DenisCarriere commented Jan 7, 2018

@rowanwins You should be able to use these now, I've published helpers, meta & invariant under the 6.0.0-beta.3 release.

You can do something like this with your HTML:

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <title>ES Modules - Single Module</title>
  </head>
  <body>
  <script type='module'>
    import {point} from "https://unpkg.com/@turf/helpers?module"
    console.log(point([100, 0]));
  </script>
  </body>
</html>
@rowanwins

This comment has been minimized.

Show comment
Hide comment
@rowanwins

rowanwins Jan 7, 2018

Member

That is cool @DenisCarriere , support for that approach is a bit patchy but will presumably continue to improve.

I was probably thinking something more like traditional turf CDN usage where you included a script and then call turf.whatever , so I guess essentially a rolledup version of every module exposing a turf global...

Anyway I'll keep thinking about it, I hadn't put loads of thought in, it was just a 'wouldnt that be nice' kinda thought the other day.

Member

rowanwins commented Jan 7, 2018

That is cool @DenisCarriere , support for that approach is a bit patchy but will presumably continue to improve.

I was probably thinking something more like traditional turf CDN usage where you included a script and then call turf.whatever , so I guess essentially a rolledup version of every module exposing a turf global...

Anyway I'll keep thinking about it, I hadn't put loads of thought in, it was just a 'wouldnt that be nice' kinda thought the other day.

@DenisCarriere

This comment has been minimized.

Show comment
Hide comment
@DenisCarriere

DenisCarriere Jan 9, 2018

Member

@rowanwins I was probably thinking something more like traditional turf CDN usage where you included a script and then call turf.whatever

Yep, you can already do that in the current Turf release, same as if you would with the global Turf CDN except using <script type='module'>.

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <title>ES Modules - Single Module</title>
  </head>
  <body>
  <script type='module'>
    import * as turf from "https://unpkg.com/@turf/turf?module"
    console.log(turf.point([100, 0]));
  </script>
  </body>
</html>

The only reason why I didn't mention this is because it's really heavy in file size (264KB).

image

Member

DenisCarriere commented Jan 9, 2018

@rowanwins I was probably thinking something more like traditional turf CDN usage where you included a script and then call turf.whatever

Yep, you can already do that in the current Turf release, same as if you would with the global Turf CDN except using <script type='module'>.

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <title>ES Modules - Single Module</title>
  </head>
  <body>
  <script type='module'>
    import * as turf from "https://unpkg.com/@turf/turf?module"
    console.log(turf.point([100, 0]));
  </script>
  </body>
</html>

The only reason why I didn't mention this is because it's really heavy in file size (264KB).

image

@DenisCarriere

This comment has been minimized.

Show comment
Hide comment
@DenisCarriere

DenisCarriere Jan 25, 2018

Member

@rowanwins support for that approach is a bit patchy but will presumably continue to improve.

Agreed, I don't think this is going to be widely adopted (just yet)...

Another approach I'm thinking of going is simply convert repo to Typescript, I've had a lot of success in my other libraries maintaining an "ES6+" source code and easily/safely transpile to ES5 friendly code.

I'll most likely close this PR and retry with Typescript (let's see where that goes...).

Member

DenisCarriere commented Jan 25, 2018

@rowanwins support for that approach is a bit patchy but will presumably continue to improve.

Agreed, I don't think this is going to be widely adopted (just yet)...

Another approach I'm thinking of going is simply convert repo to Typescript, I've had a lot of success in my other libraries maintaining an "ES6+" source code and easily/safely transpile to ES5 friendly code.

I'll most likely close this PR and retry with Typescript (let's see where that goes...).

@DenisCarriere DenisCarriere removed this from the 6.0.0 milestone Jan 25, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment