This package update succeeded based on the discovery and upstream bug reporting I performed in the previous PRs; starting from:

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

The upstream bug report + minimal repro repo:

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

Originally posted by @0xdevalias in #343 (comment)

Fixed note from the upstream bug issue:

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
• 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

Originally posted by @0xdevalias in #343 (comment)

Confirming that the fix worked on my minimal repro repo + humanify repo:

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.

Originally posted by @0xdevalias in #343 (comment)

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)