Error from CI:

Run npm run download-ci-model

> humanifyjs@2.2.2 download-ci-model
> npx humanify download 2b

node:internal/modules/cjs/loader:1631
    throw new ERR_INVALID_ARG_VALUE('filename', filename, createRequireError);
          ^

TypeError [ERR_INVALID_ARG_VALUE]: The argument 'filename' must be a file URL object, file URL string, or absolute path string. Received undefined
    at createRequire (node:internal/modules/cjs/loader:1631:11)
    at file:///Users/runner/work/humanify/humanify/dist/index.mjs:137[4](https://github.com/jehna/humanify/actions/runs/13489863907/job/37686273739?pr=343#step:7:5):18 {
  code: 'ERR_INVALID_ARG_VALUE'
}

Node.js v20.18.1
Error: Process completed with exit code 1.

This has been failing for a while:

• Bump pkgroll from 2.8.2 to 2.10.0 #322 (comment)

Installing/building/running locally, I get the same error:

⇒ npm install --ci
npm warn deprecated npmlog@6.0.2: This package is no longer supported.
npm warn deprecated are-we-there-yet@3.0.1: This package is no longer supported.
npm warn deprecated gauge@4.0.4: This package is no longer supported.

added 413 packages, and audited 414 packages in 1m

95 packages are looking for funding
  run `npm fund` for details

7 moderate severity vulnerabilities

To address issues that do not require attention, run:
  npm audit fix

Some issues need review, and may require choosing
a different dependency.

Run `npm audit` for details.
npm notice
npm notice New major version of npm available! 10.8.2 -> 11.1.0
npm notice Changelog: https://github.com/npm/cli/releases/tag/v11.1.0
npm notice To update run: npm install -g npm@11.1.0
npm notice

⇒ npm run build

> humanifyjs@2.2.2 build
> pkgroll

[plugin rollup-plugin-dynamic-import-variables] node_modules/prettier/index.mjs: invalid import "import(pathToFileURL2(file).href)". It cannot be statically analyzed. Variable dynamic imports must start with ./ and be limited to a specific directory. For example: import(`./foo/${bar}.js`).
[plugin rollup-plugin-dynamic-import-variables] node_modules/prettier/index.mjs: invalid import "import(url2)". It cannot be statically analyzed. Variable dynamic imports must start with ./ and be limited to a specific directory. For example: import(`./foo/${bar}.js`).
[plugin rollup-plugin-dynamic-import-variables] node_modules/prettier/index.mjs: invalid import "import(pathToFileURL5(name).href)". It cannot be statically analyzed. Variable dynamic imports must start with ./ and be limited to a specific directory. For example: import(`./foo/${bar}.js`).
[plugin rollup-plugin-dynamic-import-variables] node_modules/prettier/index.mjs: invalid import "import(pathToFileURL5(path12.resolve(name)).href)". It cannot be statically analyzed. Variable dynamic imports must start with ./ and be limited to a specific directory. For example: import(`./foo/${bar}.js`).
Circular dependency: node_modules/@babel/traverse/lib/index.js -> node_modules/@babel/traverse/lib/path/context.js -> node_modules/@babel/traverse/lib/traverse-node.js -> node_modules/@babel/traverse/lib/context.js -> node_modules/@babel/traverse/lib/path/index.js -> node_modules/@babel/traverse/lib/index.js
Circular dependency: node_modules/@babel/traverse/lib/traverse-node.js -> node_modules/@babel/traverse/lib/context.js -> node_modules/@babel/traverse/lib/path/index.js -> node_modules/@babel/traverse/lib/scope/index.js -> node_modules/@babel/traverse/lib/scope/lib/renamer.js -> node_modules/@babel/traverse/lib/traverse-node.js
Circular dependency: node_modules/@babel/traverse/lib/path/context.js -> node_modules/@babel/traverse/lib/traverse-node.js -> node_modules/@babel/traverse/lib/context.js -> node_modules/@babel/traverse/lib/path/index.js -> node_modules/@babel/traverse/lib/scope/index.js -> node_modules/@babel/traverse/lib/scope/lib/renamer.js -> node_modules/@babel/traverse/lib/visitors.js -> node_modules/@babel/traverse/lib/path/context.js
Circular dependency: node_modules/@babel/traverse/lib/path/context.js -> node_modules/@babel/traverse/lib/traverse-node.js -> node_modules/@babel/traverse/lib/context.js -> node_modules/@babel/traverse/lib/path/index.js -> node_modules/@babel/traverse/lib/scope/index.js -> node_modules/@babel/traverse/lib/scope/lib/renamer.js -> node_modules/@babel/traverse/lib/path/context.js
Circular dependency: node_modules/@babel/traverse/lib/index.js -> node_modules/@babel/traverse/lib/path/context.js -> node_modules/@babel/traverse/lib/traverse-node.js -> node_modules/@babel/traverse/lib/context.js -> node_modules/@babel/traverse/lib/path/index.js -> node_modules/@babel/traverse/lib/scope/index.js -> node_modules/@babel/traverse/lib/index.js
Circular dependency: node_modules/@babel/generator/lib/node/index.js -> node_modules/@babel/generator/lib/node/parentheses.js -> node_modules/@babel/generator/lib/node/index.js
Circular dependency: node_modules/@babel/traverse/lib/index.js -> node_modules/@babel/traverse/lib/path/context.js -> node_modules/@babel/traverse/lib/traverse-node.js -> node_modules/@babel/traverse/lib/context.js -> node_modules/@babel/traverse/lib/path/index.js -> node_modules/@babel/traverse/lib/path/replacement.js -> node_modules/@babel/traverse/lib/index.js
Circular dependency: node_modules/@babel/traverse/lib/path/index.js -> node_modules/@babel/traverse/lib/path/replacement.js -> node_modules/@babel/traverse/lib/path/index.js
Circular dependency: node_modules/@babel/traverse/lib/path/index.js -> node_modules/@babel/traverse/lib/path/replacement.js -> node_modules/@babel/traverse/lib/path/modification.js -> node_modules/@babel/traverse/lib/path/index.js
Circular dependency: node_modules/@babel/traverse/lib/path/context.js -> node_modules/@babel/traverse/lib/traverse-node.js -> node_modules/@babel/traverse/lib/context.js -> node_modules/@babel/traverse/lib/path/index.js -> node_modules/@babel/traverse/lib/path/replacement.js -> node_modules/@babel/traverse/lib/path/modification.js -> node_modules/@babel/traverse/lib/path/context.js
Circular dependency: node_modules/@babel/traverse/lib/path/replacement.js -> node_modules/@babel/traverse/lib/path/modification.js -> node_modules/@babel/traverse/lib/path/removal.js -> node_modules/@babel/traverse/lib/path/replacement.js
Circular dependency: node_modules/@babel/traverse/lib/path/index.js -> node_modules/@babel/traverse/lib/path/replacement.js -> node_modules/@babel/traverse/lib/path/modification.js -> node_modules/@babel/traverse/lib/path/removal.js -> node_modules/@babel/traverse/lib/path/index.js
Circular dependency: node_modules/@babel/traverse/lib/path/modification.js -> node_modules/@babel/traverse/lib/path/removal.js -> node_modules/@babel/traverse/lib/path/modification.js
Circular dependency: node_modules/@babel/traverse/lib/path/context.js -> node_modules/@babel/traverse/lib/traverse-node.js -> node_modules/@babel/traverse/lib/context.js -> node_modules/@babel/traverse/lib/path/index.js -> node_modules/@babel/traverse/lib/path/replacement.js -> node_modules/@babel/traverse/lib/path/modification.js -> node_modules/@babel/traverse/lib/path/removal.js -> node_modules/@babel/traverse/lib/path/context.js
Circular dependency: node_modules/@babel/traverse/lib/path/context.js -> node_modules/@babel/traverse/lib/traverse-node.js -> node_modules/@babel/traverse/lib/context.js -> node_modules/@babel/traverse/lib/path/index.js -> node_modules/@babel/traverse/lib/path/replacement.js -> node_modules/@babel/traverse/lib/path/context.js
Circular dependency: node_modules/@babel/traverse/lib/path/context.js -> node_modules/@babel/traverse/lib/traverse-node.js -> node_modules/@babel/traverse/lib/context.js -> node_modules/@babel/traverse/lib/path/index.js -> node_modules/@babel/traverse/lib/path/conversion.js -> node_modules/@babel/traverse/lib/path/context.js
Circular dependency: node_modules/@babel/traverse/lib/path/context.js -> node_modules/@babel/traverse/lib/traverse-node.js -> node_modules/@babel/traverse/lib/context.js -> node_modules/@babel/traverse/lib/path/index.js -> node_modules/@babel/traverse/lib/path/context.js
Circular dependency: node_modules/@babel/traverse/lib/path/index.js -> node_modules/@babel/traverse/lib/path/family.js -> node_modules/@babel/traverse/lib/path/index.js
Circular dependency: node_modules/@babel/traverse/lib/path/context.js -> node_modules/@babel/traverse/lib/traverse-node.js -> node_modules/@babel/traverse/lib/context.js -> node_modules/@babel/traverse/lib/path/context.js

⇒ npm run download-ci-model

> humanifyjs@2.2.2 download-ci-model
> npx humanify download 2b

(node:24829) [DEP0040] DeprecationWarning: The `punycode` module is deprecated. Please use a userland alternative instead.
(Use `node --trace-deprecation ...` to show where the warning was created)
node:internal/modules/cjs/loader:1762
    throw new ERR_INVALID_ARG_VALUE('filename', filename, createRequireError);
          ^

TypeError [ERR_INVALID_ARG_VALUE]: The argument 'filename' must be a file URL object, file URL string, or absolute path string. Received undefined
    at createRequire (node:internal/modules/cjs/loader:1762:11)
    at file:///Users/devalias/dev/tmp/humanify/dist/index.mjs:1374:18 {
  code: 'ERR_INVALID_ARG_VALUE'
}

Node.js v22.6.0

Looking at the code in /Users/devalias/dev/tmp/humanify/dist/index.mjs:1374:18:

// ..snip..
/* 1373 */ const import_meta = {};
/* 1374 */ const require2 = createRequire(import_meta.url);
/* 1375 */ const __filename = fileURLToPath(import_meta.url);
/* 1376 */ dirname(__filename);
/* 1377 */ var __create = Object.create;
/* 1378 */ var __defProp2 = Object.defineProperty;
/* 1379 */ var __getOwnPropDesc = Object.getOwnPropertyDescriptor;
/* 1380 */ var __getOwnPropNames = Object.getOwnPropertyNames;
/* 1381 */ var __getProtoOf = Object.getPrototypeOf;
/* 1382 */ var __hasOwnProp2 = Object.prototype.hasOwnProperty;
// ..snip..

So it seems the error is because import_meta.url is undefined.

I would have to research/debug deeper to understand more about the root cause of that, and how to fix it.

This seems like a similar issue potentially?

• shims for __dirname so one code can output to both esm and cjs privatenumber/pkgroll#61 (comment)

Also these ones in esbuild:

• import.meta.url support evanw/esbuild#1492
  • Has a few potential workarounds/ideas/etc
• 🐞 import.meta.url transpile. evanw/esbuild#2441
• [feat] auto shim import.meta.url for cjs output evanw/esbuild#3099
• [Documentation] Document the failure mode for unsupported node-specific features in dependencies evanw/esbuild#3632
• etc

Attempting to run the same code directly from the non-built source seems to work:

⇒ npm start download 2b

> humanifyjs@2.2.2 start
> tsx src/index.ts download 2b

(node:25887) [DEP0040] DeprecationWarning: The `punycode` module is deprecated. Please use a userland alternative instead.
(Use `node --trace-deprecation ...` to show where the warning was created)
Model "2b" already downloaded

Attempting to run the built code at all seems to fail with the same error (so it doesn't seem to be related to the model download code specifically):

⇒ node dist/index.mjs
(node:26559) [DEP0040] DeprecationWarning: The `punycode` module is deprecated. Please use a userland alternative instead.
(Use `node --trace-deprecation ...` to show where the warning was created)
node:internal/modules/cjs/loader:1762
    throw new ERR_INVALID_ARG_VALUE('filename', filename, createRequireError);
          ^

TypeError [ERR_INVALID_ARG_VALUE]: The argument 'filename' must be a file URL object, file URL string, or absolute path string. Received undefined
    at createRequire (node:internal/modules/cjs/loader:1762:11)
    at file:///Users/devalias/dev/tmp/humanify/dist/index.mjs:1374:18 {
  code: 'ERR_INVALID_ARG_VALUE'
}

Node.js v22.6.0

Looking for similar errors:

• https://stackoverflow.com/questions/77212131/prettier-createrequire-the-argument-filename-must-be-a-file-url-object-file

  • I am using prettier programmatically, in code, with the format(jsCodeString) function. The code works locally, but when I bundle it with esbuild, in production prettier fails when it tries to dynamically import some module.

    I get the following error: The argument 'filename' must be a file URL object, file URL string, or absolute path string. Received undefined

    I don't know what prettier is looking for so I don't know how to fix it. I haven't found this error anywhere else on the internet.

  • In my situation, I'm building for a NodeJS target, and I don't need the portability to ship the bundle without node_modules. If you're in a similar position then you can make use of ESBuild's external property. The external property should prevent ESBuild from trying to bundle Prettier, and just require it directly from node_modules

• https://oss.issuehunt.io/r/storybookjs/storybook/issues/11587

  • For projects configured to use native ES modules in node.js via the "type": "module" configuration in package.json (https://nodejs.org/api/esm.html#esm_package_json_type_field), Storybook cannot require() the main.js configuration file, because node does not support require() for this package type. We also cannot rename it to main.cjs to allow the use of require(), because Storybook does not recognize that file.

The above talk about esbuild; while we are using pkgroll, which is powered by rollup, and also uses esbuild:

• https://github.com/privatenumber/pkgroll#target

  • Pkgroll uses esbuild to handle TypeScript and JavaScript transformation and minification.

It seems pkgroll determines how to bundle things based on parsing various aspects of the package.json file:

• https://github.com/privatenumber/pkgroll#usage

  • Pkgroll parses package entry-points from package.json by reading properties main, module, types, and exports

  • Pkgroll detects the format for each entry-point based on the file extension or the package.json property it's placed in, using the same lookup logic as Node.js.

  • Auto-detect infers the type by extension or package.json#type

    • • .mjs: ECMAScript Modules

• https://github.com/privatenumber/pkgroll#dependency-bundling--externalization

  • Dependency bundling & externalization

    Packages to externalize are detected by reading dependency types in package.json. Only dependencies listed in devDependencies are bundled in.

prettier is in devDependencies, so based on that, it will presumably be bundled in.

It seems rollup does have a compatibility mode for CommonJS support:

• https://github.com/rollup/rollup#compatibility

  • Importing CommonJS

    Rollup can import existing CommonJS modules through a plugin.

    • https://github.com/rollup/plugins/tree/master/packages/commonjs

      • @rollup/plugin-commonjs

        A Rollup plugin to convert CommonJS modules to ES6, so they can be included in a Rollup bundle

      • Requirements

        This plugin requires an LTS Node version (v14.0.0+) and Rollup v2.68.0+. If you are using @rollup/plugin-node-resolve, it should be v13.0.6+.

And we can see more ESM / CJS compatibility notes for pkgroll here:

• https://github.com/privatenumber/pkgroll#esm--cjs-interoperability

  • ESM ⇄ CJS interoperability

    Node.js ESM offers interoperability with CommonJS via static analysis. However, not all bundlers compile ESM to CJS syntax in a way that is statically analyzable.

    Because pkgroll uses Rollup, it's able to produce CJS modules that are minimal and interoperable with Node.js ESM.

    This means you can technically output in CommonJS to get ESM and CommonJS support.

    require() in ESM

    Sometimes it's useful to use require() or require.resolve() in ESM. ESM code that uses require() can be seamlessly compiled to CommonJS, but when compiling to ESM, Node.js will error because require doesn't exist in the module scope.

    When compiling to ESM, Pkgroll detects require() usages and shims it with createRequire(import.meta.url).

So from that, we can see that pkgroll has detected require usage in a package we're using (likely prettier), and shimmed it with createRequire(import.meta.url).

So the next step would be figuring out why import.meta.url is resolving to undefined currently.

A potential alternative could also be moving prettier out of devDependencies so it's not bundled.. but I'm not sure what would influence whether that's a good decision one way or another; or if there is a better more direct fix.

See also:

• https://esbuild.github.io/getting-started/#bundling-for-node

  • You also may not want to bundle your dependencies with esbuild. There are many node-specific features that esbuild doesn't support while bundling such as __dirname, import.meta.url, fs.readFileSync, and *.node native binary modules. You can exclude all of your dependencies from the bundle by setting packages to external

  • If you do this, your dependencies must still be present on the file system at run-time since they are no longer included in the bundle.

So it looks like prettier has had ESM module support since v3.0:

• https://prettier.io/blog/2023/07/05/3.0.0.html

  • We have made the migration to using ECMAScript Modules for all our source code. This change has significantly improved the development experience for the Prettier team. Please rest assured that when using Prettier as a library, you can still use it as CommonJS as well.

  • Can see breaking changes for API usage here: https://prettier.io/blog/2023/07/05/3.0.0.html#api-1
    • Use named export instead of default export prettier/prettier#12740
      • https://unpkg.com/browse/prettier@3.0.0/package.json

This is where prettier is being used programatically, and then this re-export is consumed in other places throughout the app:

Looking at package-lock.json:

It seems to work fine with pkgroll 2.9.0, but starts breaking from 2.10.0:

• https://github.com/privatenumber/pkgroll/releases/tag/v2.9.0
• https://github.com/privatenumber/pkgroll/releases/tag/v2.10.0

  • enhance env replacement with esbuild (4ae9c67)

    • This commit seems to remove @rollup/plugin-replace, and passes env into esbuildConfig's define key.
      • https://github.com/rollup/plugins/tree/master/packages/replace#readme

        • @rollup/plugin-replace

          A Rollup plugin which replaces targeted strings in files while bundling.

      • https://esbuild.github.io/api/#define

        • This feature provides a way to replace global identifiers with constant expressions. It can be a way to change the behavior some code between builds without changing the code itself

Looking at the code in /Users/devalias/dev/tmp/humanify/dist/index.mjs:1374:18:

// ..snip..
/* 1373 */ const import_meta = {};
/* 1374 */ const require2 = createRequire(import_meta.url);
/* 1375 */ const __filename = fileURLToPath(import_meta.url);
/* 1376 */ dirname(__filename);
/* 1377 */ var __create = Object.create;
/* 1378 */ var __defProp2 = Object.defineProperty;
/* 1379 */ var __getOwnPropDesc = Object.getOwnPropertyDescriptor;
/* 1380 */ var __getOwnPropNames = Object.getOwnPropertyNames;
/* 1381 */ var __getProtoOf = Object.getPrototypeOf;
/* 1382 */ var __hasOwnProp2 = Object.prototype.hasOwnProperty;
// ..snip..

So it seems the error is because import_meta.url is undefined.

Looking at /Users/devalias/dev/tmp/humanify/node_modules/prettier/index.mjs, we can more or less match up those lines:

import { createRequire as __prettierCreateRequire } from "module";
import { fileURLToPath as __prettierFileUrlToPath } from "url";
import { dirname as __prettierDirname } from "path";
const require = __prettierCreateRequire(import.meta.url);
const __filename = __prettierFileUrlToPath(import.meta.url);
const __dirname = __prettierDirname(__filename);

var __create = Object.create;
var __defProp = Object.defineProperty;
var __getOwnPropDesc = Object.getOwnPropertyDescriptor;
var __getOwnPropNames = Object.getOwnPropertyNames;
var __getProtoOf = Object.getPrototypeOf;
var __hasOwnProp = Object.prototype.hasOwnProperty;

But we can see that import.meta.url is left as-is in the prettier .mjs; whereas it's being transpiled in our version for some reason.

I've opened an upstream bug report for this with pkgroll + created a minimal reproduction repo for it:

• TypeError [ERR_INVALID_ARG_VALUE]: The argument 'filename' must be a file URL object, file URL string, or absolute path string. Received undefined at createRequire privatenumber/pkgroll#115
  • https://github.com/0xdevalias/min-repro-pkgroll-2-10-0-regression

I've opened an upstream bug report for this with pkgroll

Notes from the upstream bug issue:

Appreciate the extremely thorough reproduction and investigation! Made it a lot easier to identify the issue.

It's happening because we started using esbuild as a more accurate alternative to @rollup/plugin-replace, which has this behavior:
https://esbuild.github.io/try/#dAAwLjI1LjAAe3RhcmdldDogWydlczIwMTcnXX0AY29uc29sZS5sb2coaW1wb3J0Lm1ldGEudXJsKQ

The fix is simply turning it off. Fix will be released soon.

Originally posted by @privatenumber in #115

Was fixed in this commit:

• privatenumber/pkgroll@f313e1f

And released in pkgroll 2.11.1`:

• https://github.com/privatenumber/pkgroll/releases/tag/v2.11.1

By setting esbuild's supported for import-meta to true:

• https://esbuild.github.io/api/#supported

  • Supported
    Supported by: Build and Transform

    This setting lets you customize esbuild's set of unsupported syntax features at the individual syntax feature level. For example, you can use this to tell esbuild that BigInts are not supported so that esbuild generates an error when you try to use one. Usually this is configured for you when you use the target setting, which you should typically be using instead of this setting. If the target is specified in addition to this setting, this setting will override whatever is specified by the target.

• https://esbuild.github.io/api/#target

  • Target
    Supported by: Build and Transform

    This sets the target environment for the generated JavaScript and/or CSS code. It tells esbuild to transform JavaScript syntax that is too new for these environments into older JavaScript syntax that will work in these environments.

  • In addition, you can also specify JavaScript language versions such as es2020. The default target is esnext which means that by default, esbuild will assume all of the latest JavaScript and CSS features are supported. Here is an example that configures multiple target environments. You don't need to specify all of them; you can just specify the subset of target environments that your project cares about. You can also be more precise about version numbers if you'd like (e.g. node12.19.0 instead of just node12)

  • You can refer to the JavaScript loader for the details about which syntax features were introduced with which language versions. Keep in mind that while JavaScript language versions such as es2020 are identified by year, that is the year the specification is approved. It has nothing to do with the year all major browsers implement that specification which often happens earlier or later than that year.

    • https://esbuild.github.io/content-types/#javascript

      • import.meta, transformed when --target is below es2020

We can see various node versions and the features that they have compatibility with here (though at least from a quick skim.. I couldn't see import.meta listed there, unless under a different name):

• https://node.green/
  • https://node.green/#ES2015
  • https://node.green/#ES2016
  • https://node.green/#ES2017
  • https://node.green/#ES2018
  • https://node.green/#ES2019
  • https://node.green/#ES2020
  • https://node.green/#ES2021
  • https://node.green/#ES2022
  • https://node.green/#ES2023
  • https://node.green/#ES2024
  • https://node.green/#ES2025
  • https://node.green/#ESNEXT
  • https://github.com/williamkapke/node-compat-table

    • node.green - Node.js ECMAScript compatibility tables

• https://compat-table.github.io/compat-table/es6/
  • https://github.com/compat-table/compat-table

    • ECMAScript compatibility tables

So I opened some upstream issues for that:

• Add import.meta.dirname / import.meta.filename (available since node 20.11.0) compat-table/node-compat-table#92
• javascript.operators.import_meta - Missing import.meta.dirname / import.meta.filename support for node mdn/browser-compat-data#26066
• Missing import.meta.dirname / import.meta.filename support for node mdn/content#38335
  • https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/import.meta

We can see more about when import.meta was introduced here:

• https://github.com/tc39/proposal-import-meta
• Add import.meta.directory and import.meta.file properties nodejs/node#47756
• esm: add import.meta.dirname and import.meta.filename nodejs/node#48740
  • Skimming through this PR, it seems import.meta.dirname/similar support was introduced in node 20.11.0

We can confirm that in the node docs, seeing that only import.meta.url / import.meta.resolve are available in node 19.x:

• https://nodejs.org/docs/latest-v19.x/api/esm.html#importmeta

But from node 20.x+, import.meta.dirname / import.meta.filename are also available:

• https://nodejs.org/docs/latest-v20.x/api/esm.html#importmeta

Was fixed in this commit:

• privatenumber/pkgroll@f313e1f

And released in pkgroll 2.11.1`:

• privatenumber/pkgroll@v2.11.1 (release)

Confirmed that pkgroll 2.11.1 seems to fix the build issues:

Bumped to 2.11.1 in 0xdevalias/min-repro-pkgroll-2-10-0-regression@1293f40

And confirm it seems to work again for my repro repo! 🎉

⇒ npm run build

> min-repro-pkgroll-2-10-0-regression@0.0.1 build
> pkgroll

[plugin rollup-plugin-dynamic-import-variables] node_modules/prettier/index.mjs: invalid import "import(pathToFileURL2(file).href)". It cannot be statically analyzed. Variable dynamic imports must start with ./ and be limited to a specific directory. For example: import(`./foo/${bar}.js`).
[plugin rollup-plugin-dynamic-import-variables] node_modules/prettier/index.mjs: invalid import "import(url2)". It cannot be statically analyzed. Variable dynamic imports must start with ./ and be limited to a specific directory. For example: import(`./foo/${bar}.js`).
[plugin rollup-plugin-dynamic-import-variables] node_modules/prettier/index.mjs: invalid import "import(pathToFileURL5(name).href)". It cannot be statically analyzed. Variable dynamic imports must start with ./ and be limited to a specific directory. For example: import(`./foo/${bar}.js`).
[plugin rollup-plugin-dynamic-import-variables] node_modules/prettier/index.mjs: invalid import "import(pathToFileURL5(path12.resolve(name)).href)". It cannot be statically analyzed. Variable dynamic imports must start with ./ and be limited to a specific directory. For example: import(`./foo/${bar}.js`).

⇒ npm test

> min-repro-pkgroll-2-10-0-regression@0.0.1 test
> node dist/index.mjs

It worked!

---

Testing with a local checkout of humanify and bumping pkgroll to 2.11.1 also seems like it works! 🎉

Originally posted by @0xdevalias in privatenumber/pkgroll#115 (comment)

I won't bother creating a new PR for this, as dependabot will see the pkgroll 2.11.1 release and create a new/updated PR for it within the day; which will then get automerged when the tests pass.

Deepdive/Writeup:

FYI: I did a bit of a deepdive/writeup of the underlying aspects/specifics of this in this StackOverflow answer:

• https://stackoverflow.com/questions/77212131/prettier-createrequire-the-argument-filename-must-be-a-file-url-object-file/79471727#79471727

Which I also made a gist of for posterity, and shared on my relevant socials (1, 2, 3)

Originally posted by @0xdevalias in privatenumber/pkgroll#115 (comment)

Superseded by #347.