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

Indicate the ES publication in package.json #20062

Closed
1 task done
sveyret opened this issue Mar 11, 2020 · 3 comments
Closed
1 task done

Indicate the ES publication in package.json #20062

sveyret opened this issue Mar 11, 2020 · 3 comments
Labels
duplicate This issue or pull request already exists

Comments

@sveyret
Copy link
Contributor

sveyret commented Mar 11, 2020

I would like to be able to use the ES version of material-ui in a project using a modern node version (> 13.7).

  • I have searched the issues of this repository and believe that this is not a duplicate.

Summary 💡

As stated in the NodeJS 13 doc, the ES module entry point for NodeJS should not be specified in a module entry, but in an exports structure.

A NodeJS project could automatically use the ES version if this version was indicated in the package.json file:

// package.json
{
  ...
  "main": "./index.js",
  "module": "./esm/index.js",
  "typings": "./index.d.ts",
  "exports": {
    "import": "./es/index.js",
    "require": "./index.js"
  }
}

This would probably also require to change the js extension into mjs or to write another package.json file in the es folder containing at least (as stated here):

{
  "type": "module"
}

Examples 🌈

This would allow to do something like:

import { Card, CardMedia, Paper, Theme, Typography } from '@material-ui/core'

whether in a ES module or a CommonJS project.

Motivation 🔦

In Node 13, ES modules are enabled by default (they don't require an experimental flag as for previous versions). Because more and more browser also conform to ES modules, developers will probably soon want to use them everywhere. As ES modules are already published by material-ui, I feel this would not be a big work to make them easily accessible.

We can, of course, directly import the es sub-folder, but:

  • it is considered bad practice by linters,
  • when using TypeScript, types cannot be associated to files in the es folder.

Note: this issue may be related to #18447.

@eps1lon
Copy link
Member

eps1lon commented Mar 11, 2020

This would allow to do something like:

Your example is already supported. Did this stop working in node 13?

We can, of course, directly import the es sub-folder

We don't recommend this. Use aliases in your build process instead.

Closing this in favor of #18447. The esmodule story of node will be part of this story. But we have to draw up a concrete plan. I'm especially concerned that the new esm API did not account for different bundle targets beyond the used module (modern, es6, ie11 etc.)

@eps1lon eps1lon closed this as completed Mar 11, 2020
@sveyret
Copy link
Contributor Author

sveyret commented Mar 11, 2020

Your example is already supported. Did this stop working in node 13?

It is not working when writing ES module in node (either using node 13, or node 12 with --experimental-modules, not sure for previous versions, and setting "type": "module" in the package.json).

This is because it is impossible to destructure an imported CommonJS module from an ES module. You have to do:

import * as mui from '@material-ui/core'
const { Card, CardMedia, Paper, Theme, Typography } = mui

The main point is that the module entry is not read by node, you have to create an exports structure in package.json.

@eps1lon
Copy link
Member

eps1lon commented Mar 11, 2020

Ok thanks for the heads-up. We don't support experimental flags or non-lts node versions though. We'll figure this out once node 14 is released.

@zannager zannager added the duplicate This issue or pull request already exists label Dec 20, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
duplicate This issue or pull request already exists
Projects
None yet
Development

No branches or pull requests

3 participants