Meteor 3.0: type:module in package.json causes error

3.0 migration
1

When I set "type": "module" in package.json in a 3.0 beta.0 project, I get an error from Meteor:

W20240105-23:21:25.297(-8)? (STDERR) file:///Users/trusktr/src/lume+lume/apps/website/.meteor/local/build/main.js:3
W20240105-23:21:25.301(-8)? (STDERR) process.chdir(require('path').join(__dirname, 'programs', 'server'));
W20240105-23:21:25.301(-8)? (STDERR)         ^
W20240105-23:21:25.301(-8)? (STDERR) 
W20240105-23:21:25.302(-8)? (STDERR) ReferenceError: require is not defined in ES module scope, you can use import instead
W20240105-23:21:25.302(-8)? (STDERR) This file is being treated as an ES module because it has a '.js' file extension and '/Users/trusktr/src/lume+lume/apps/website/package.json' contains "type": "module". To treat it as a CommonJS script, rename it to use the '.cjs' file extension.
W20240105-23:21:25.302(-8)? (STDERR)     at file:///Users/trusktr/src/lume+lume/apps/website/.meteor/local/build/main.js:3:9
W20240105-23:21:25.302(-8)? (STDERR)     at ModuleJob.run (node:internal/modules/esm/module_job:217:25)
W20240105-23:21:25.302(-8)? (STDERR)     at async ModuleLoader.import (node:internal/modules/esm/loader:316:24)
W20240105-23:21:25.302(-8)? (STDERR)     at async loadESM (node:internal/process/esm_loader:34:7)
W20240105-23:21:25.302(-8)? (STDERR)     at async handleMainPromise (node:internal/modules/run_main:66:12)
W20240105-23:21:25.302(-8)? (STDERR) 
W20240105-23:21:25.302(-8)? (STDERR) Node.js v20.9.0

I was hoping to remove the ecmascript package so that code will run as vanilla ES modules.

This problem is for server code.

For client code we can easily place vanilla ES modules inside of public/ and use a <script type="importmap"> to satisfy dependencies and run all code as plain JS modules. This has been working great for me already (example project with clientside ES modules here). The downside of this is, of course, that we cannot opt into any build-time optimizations with Meteor such as minification or bundling. However, I think this shows a nice starting point to how code should work by default, and the Meteor can optimize code based on this setup.

1 Like