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

[meta] Support ES Module natively #421

Closed
2 of 4 tasks
tetsuharuohzeki opened this issue Jul 28, 2019 · 13 comments
Closed
2 of 4 tasks

[meta] Support ES Module natively #421

tetsuharuohzeki opened this issue Jul 28, 2019 · 13 comments

Comments

@tetsuharuohzeki
Copy link
Contributor

tetsuharuohzeki commented Jul 28, 2019

After a long time to wait, finally, we would be able to use ES Module natively.
This issue tracks issues to support ES Module as 1st citizen of this package.

Tasks

  1. Should we drop to support versions which does not have support ES Module?
  2. Set "type": "module" to package.json.
  3. Remove .js or .mjs from option-t/esm.
  4. Reconsider the structure under option-t/lib.

Related Links

@tetsuharuohzeki
Copy link
Contributor Author

@tetsuharuohzeki
Copy link
Contributor Author

By these document, Dual CommonJS/ES module packages, which we would like to do, we need to wait more times to stabilize --experimental-conditional-exports.

@tetsuharuohzeki
Copy link
Contributor Author

We drop .js files from esm/ by #504

@tetsuharuohzeki
Copy link
Contributor Author

By #520, we can use import 'option-t/esm/unwrap.mjs';

@tetsuharuohzeki
Copy link
Contributor Author

In v22, we ships to allow import .mjs.

@tetsuharuohzeki
Copy link
Contributor Author

Interestingly, I seem Node v12.16 supports ESM features natively by backporting them.
Their backports almost have the same degree of Node.js v13.8

@tetsuharuohzeki
Copy link
Contributor Author

Interestingly, I seem Node v12.16 supports ESM features natively by backporting them.
Their backports almost have the same degree of Node.js v13.8

By the behavior, it was jump to conclusions.

@tetsuharuohzeki
Copy link
Contributor Author

@kogai
Copy link

kogai commented Sep 16, 2020

I'm not sure if this is an appropriate request, but could you consider adding package.json to the exports field?

For example, in the case of using serverless-plugin-monorepo.
(FYI: It is a dependencies-resolve-helper for deploying the serverless function which developed as a monorepo package)

It seems trying to resolve package.json of each npm packages when resolving dependencies of some monorepo packages.
https://github.com/Butterwire/serverless-plugin-monorepo/blob/82991befe9fd6aeaa37cebf811be4213fa590379/index.js#L59

So if some npm package has defined exports field and doesn't define package.json in exports, serverless-plugin-monorepo can’t resolve packages properly.
I think it would be the same for any other npm package that needs to read package.json.

@tetsuharuohzeki
Copy link
Contributor Author

@kogai I filed your problem as #726

I’d like to handle this issue separately from this issue because it should be handled as the defail of this task. Feel free to open a new issue from the next time.

@tetsuharuohzeki tetsuharuohzeki added this to the Migrate to post-ESM milestone Nov 4, 2020
@tetsuharuohzeki
Copy link
Contributor Author

webpack v5 supports Node's export fields and @rollup/plugin-node-resolve also supported it in v11.

After esbuild's stable version support it, we can start to drop lib/ compat dir.

@tetsuharuohzeki
Copy link
Contributor Author

After esbuild's stable version support it, we can start to drop lib/ compat dir.

This moved to #808

@tetsuharuohzeki
Copy link
Contributor Author

As a library package, we have completed to support ES Module. We close this once.

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

No branches or pull requests

2 participants