Feature: Support package.json exports fields

[flean]

Right now I'm stuck with version 6 of swiper and would like to upgrade to 7 but it requires ESM support.

Is there a way for us to use ESM packages in meteor?

SwiperJS

the title was firstly named: ESM packages support

[StorytellerCZ]

I don't follow, are you getting an error when you are trying to import from Swipper 7?

For example:

import Swiper from 'swiper/swiper-bundle.esm.js';

or

import Swiper from 'swiper';

[flean]

// Import Swiper React components
import { Swiper, SwiperSlide } from 'swiper/react';

// Import Swiper styles
import 'swiper/css';

[StorytellerCZ]

Shouldn't it be?

import Swiper, { SwiperSlide } from 'swiper/react';

[flean]

No, that comes directly from their docs and the react component inherits swiper core. At least thats my understanding.

[StorytellerCZ]

I still don't understand what the problem here is.

[flean]

It can’t find the module, app breaks. I have to use version 6 for it to work. It looks like meteor can’t use ESM packages. I’ll setup a meteor app only loading that component.

[flean]

here is the repo with version 7

Server

Unable to resolve some modules:

  "swiper/css" in /simple-swiper-example/imports/ui/App.jsx (web.browser)

If you notice problems related to these missing modules, consider running:

  meteor npm install --save swiper

Client Side

[Log] HMR: connected (hot-module-replacement.js, line 330)
[Error] Error: Cannot find module 'swiper/react'
	(anonymous function) (modules-runtime-hot.js:253)
	moduleLink (modules.js:300)
	module (app.js:55)
	fileEvaluate (modules-runtime-hot.js:388)
	require (modules-runtime-hot.js:270)
	moduleLink (modules.js:307)
	module (app.js:218)
	fileEvaluate (modules-runtime-hot.js:388)
	require (modules-runtime-hot.js:270)
	Global Code (app.js:240)

[StorytellerCZ]

OK, I see now!

Yeah, that is indeed not working. Right now workaround would be to import from the files directly like this:

import 'swiper/swiper.min.css';

But that is only a stop gap solution.

@zodern @renanccastro @filipenevola
The issue here is that in package.json the exports are defined under exports prop, in this case like this:

"exports": {
    ".": "./swiper.esm.js",
    "./core": "./swiper.esm.js",
    "./bundle": "./swiper-bundle.esm.js",
    "./css": "./swiper.min.css",
    "./css/bundle": "./swiper-bundle.min.css",
    "./css/a11y": "./modules/a11y/a11y.min.css",
    "./css/autoplay": "./modules/autoplay/autoplay.min.css",
...

[trusktr]

Even TypeScript barely just added support for recognizing package.json exports fields. Meteor's turn now.

The only solution right now is to import the files directly until Meteor adds support for it as well.

Keep one thing in mind about this workaround though: importing files directly will work in Meteor, but will fail in Node apps, or in Webpack which also follows the latest Node ESM spec. If you have some code in package A, for example, and it imports files directly from some package B, this will work in Meteor, but it will throw an error in Node or Webpack apps.

[trusktr]

This is a duplicate of #10906

[StorytellerCZ]

Some notes from me digging around this:
Babel plans to become ESM package in Babel 8: https://babeljs.io/docs/en/roadmap#babel-8
There is this esm package which should make things work: https://www.npmjs.com/package/esm
But Node should supporting this already: https://nodejs.org/docs/latest-v14.x/api/esm.html

[make-github-pseudonymous-again]

Is this something that only needs an upstream (upcoming) update of TypeScript?

[trusktr]

For TypeScript support specifically, yes. For now, importing packages with an exports field in package.json won't work (it might, if you get lucky, but it depend on each package). microsoft/TypeScript#33079

For Meteor in general, no, because package.json exports field and Node ESM module resolution doesn't have to do with TypeScript (TypeScript doesn't support the features yet, but once it does, Meteor still needs to build file correctly, independently of TypeScript).

[StorytellerCZ]

I don't think that will be it. I think the problem here for me is to pin the issue down. Meteor already supports what is commonly known as JavaScript modules. What we are talking about here is a new feature which allows developers to specify their exports under export param in package.json which we can't process here. Given that we have special handling for things like inline imports, maybe we need to update other parts as well. Any thoughts @zodern @renanccastro ?

[zodern]

It seems this mostly affects how modules are resolved. In Meteor this would be implemented here in install and here in the Meteor tool. This seems to be the current specification.

[StorytellerCZ]

Here is the relevant docs from Node.js: https://nodejs.org/api/packages.html#packages_exports
TypeScript is implementing this in 4.5: https://devblogs.microsoft.com/typescript/announcing-typescript-4-5-beta/#packagejson-exports-imports-and-self-referencing

[trusktr]

Nice.

Regardless of TypeScript though, this needs to be implemented in Meteor's loader (meteorInstall and related tooling).

[edemaine]

I just ran into this issue, specifically the desire for export conditions (see this Node documentation). I'm using the solid-js package, which offers a regular main entry point, but also uses exports to define specific exports when in "development" mode with additional debugging code.

So when implementing support for exports, it'd be really sweet for meteor run to enable the "development" condition, while meteor build would not.

[StorytellerCZ]

Found a related issue in Reify with comment from @benjamn : benjamn/reify#329

[trusktr]

There is this esm package which should make things work: https://www.npmjs.com/package/esm

The esm package is out of date and does not support Node ESM spec, so it will fail to import various Node ESM packages from node_modules.

Node should supporting this already: https://nodejs.org/docs/latest-v14.x/api/esm.html

Node supports it, but code in Meteor that passes through Meteor's build system ecmascript by @benjamn won't work with Node ESM format. Meteor needs to

• update ecmascript to support it (reify issue in the previous comment), and
• make it easy to not use ecmascript on the server so that native Node ESM can be used instead

No matter what, if we're bundling code for the client, then we need to support Node ESM format to be compatible with packages that are moving forward to Node ESM.

Package authors should avoid the exports field of package.json so as to be compatible with both TypeScript and Meteor.

[edemaine]

Using native ESM on server would be nice, but given that Reify/Meteor modules already supports import syntax well, an alternative approach is to just emulate the exports feature. I don't think it would be hard, but I don't know what isometric assumptions Reify makes. Meteor is already not isometric between client and server (e.g. legacy vs not builds) so I feel like it should be possible.

[eric-burel]

I don't get the "avoid exports" bit. I've noticed that Apollo does avoid it, however exports map seem to be a core feature of npm. I've written my own packages using exports map and I am happy with them so far.

[trusktr]

In my opinion, this should not be a GitHub discussion, but an issue. This is fairly critical, not a discussion topic for debate, and as more packages become Node ESM-flavored on npm, Meteor is going to lose compatibility with those packages.

At some point, the lack of support will be considered a bug, and it should be acted on in order to keep Meteor relevant.

[eric-burel]

Hi, you might want to take a look at "file-type", this is an example of a package that do not work with Meteor: https://www.npmjs.com/package/file-type

However to be completely fair, many packages may have weird exports and are not supported by many bundlers. For instance, @apollo/client doesn't load correctly in Next.js, and other Webpack 5-based bundlers, when it's a dependency of another ESM modules (like a package that exposes some hooks based on Apollo), because it doesn't have exports map.

[StorytellerCZ]

This just landed on Reify issue tracker, not sure about it, but might be useful: benjamn/reify#365

[ajaypillay]

Hi, I've stumbled upon the ESM issue here:

https://github.com/orgs/mdx-js/discussions/2088
mdx-js/mdx#2085

I was wondering what the progress/stance is on whether Meteor is going to be supporting ESM packages, as I don't see any conclusion on what we should be doing moving forward. Thanks.

[StorytellerCZ]

Right now the Fibers issue takes priority over the others. I think we can expect movement on this after that.
On the Typescript side I think updating to 4.7 will be related to this as well from what I remember from the changelog.

[Grubba27]

As commented by @StorytellerCZ and requested by @zodern, I've updated the discussion name from:
ESM packages support -> Feature: Support package.json exports field.
If the name is still misleading, I can rename this until it makes sense :)
Will update our roadmap with this discussion changes in a moment.

[jtarvainen]

Apologies if this is a silly question or the wrong place to ask, but should it be possible to create a Meteor app as an ESM? I've set up my project as an ESM, but this causes meteor run to crash with the following error:

file:///my-app-path/.meteor/local/build/main.js:3
process.chdir(require('path').join(__dirname, 'programs', 'server'));
^

ReferenceError: require is not defined in ES module scope, you can use import instead
This file is being treated as an ES module because it has a '.js' file extension and '/my-app-path/package.json' contains "type": "module". To treat it as a CommonJS script, rename it to use the '.cjs' file extension.
at file:///my-app-path/.meteor/local/build/main.js:3:9
at ModuleJob.run (internal/modules/esm/module_job.js:183:25)
at async Loader.import (internal/modules/esm/loader.js:178:24)
at async Object.loadESM (internal/process/esm_loader.js:68:5)
at async handleMainPromise (internal/modules/run_main.js:59:12)

Is there any way to avoid this?

[zodern]

Meteor transpiles ESM and internally uses require when it builds the app. Your app should run fine without having this error. It would be good to create a new issue for this bug.

[jtarvainen]

OK, thanks! I tried setting "type": "module" in my Meteor project's package.json, but that doesn't seem to work.

[brucejo75]

@Grubba27, @StorytellerCZ, Should this issue be considered in v3.0? Newer packages have started using it.

Thanks!

[StorytellerCZ]

Yes in the 3.x release line, not for 3.0 as that is already a big enough on its own and adding more onto it at this late stage will just delay it further.

[jankapunkt]

I think this should have been added way before 3.0 if Meteor finally wants to not only keep up but stay ahead of the majority of the broader ecosystem.

[domq]

I think I'm encountering this issue with Angular, see Urigo/angular-meteor#1988

[StorytellerCZ]

Babel v8 is going to be ESM only: https://babeljs.io/docs/v8-migration