Your message dated Wed, 30 Dec 2020 07:51:06 +1100
with message-id <[email protected]>
and subject line Re: [Pkg-javascript-devel] Bug#960901: Buffer is a built-in 
node function
has caused the Debian Bug report #960901,
regarding webpack: Resolver falsely detects phantom ‘buffer’ import in ‘clone’ 
library
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)


-- 
960901: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960901
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: webpack
Version: 4.43.0-1
Severity: normal

When I create a minimal project that imports the ‘clone’ library,
Webpack reports that it cannot resolve an import of ‘buffer’:

=====
ERROR in /usr/share/nodejs/clone/clone.js
Module not found: Error: Can't resolve 
'./../../../../tmp/app-using-clone.AIFQnn/buffer' in '/usr/share/nodejs/clone'
 @ /usr/share/nodejs/clone/clone.js 1:0-58
 @ ./source/main.js
=====

There is no attempt in that library to import ‘buffer’. The path in
the error message should never be used and is not present in the
‘clone’ library.

The ‘clone’ library is the ‘/usr/share/nodejs/clone/clone.js’
installed from Debian.

Webpack is not reporting correctly where it is finding this import. So
it is not clear, from that error message, what is causing Webpack to
detect a ‘buffer’ name that it then cannot resolve.


Here is a demonstration of how I invoked the above error:

=====
$ dpkg-query --list node-clone | grep '^i'
ii  node-clone     2.1.2-2      all          deep cloning of objects and arrays

$ cd $(mktemp --tmpdir --directory 'app-using-clone.XXXXXX')

$ mkdir source/
$ cat > source/main.js
"use strict";
import clone from 'clone';

$ cat > webpack-config.js
"use strict";

const path = require('path');

const rootDir = path.resolve(__dirname);
const sourceDir = path.resolve(rootDir, 'source');
const buildDir = path.resolve(rootDir, 'build');

module.exports = {
    mode: 'development',
    entry: {
        app: path.resolve(sourceDir, 'main.js'),
    },
    output: {
        path: buildDir,
        filename: 'app.js',
    },
    resolve: {
        modules: [
            sourceDir,
            '/usr/share/javascript',
            '/usr/share/nodejs',
        ],
    },
};

$ webpack --config webpack-config.js
Hash: eceaa9ff3519c5b14efb
Version: webpack 4.43.0
Time: 111ms
Built at: 18/05/2020 1:09:24 pm
 Asset      Size  Chunks             Chunk Names
app.js  12.1 KiB     app  [emitted]  app
Entrypoint app = app.js
[../../usr/share/nodejs/clone/clone.js]
/usr/share/nodejs/clone/clone.js 7.12 KiB {app} [built]
[./source/main.js] 42 bytes {app} [built]

ERROR in /usr/share/nodejs/clone/clone.js
Module not found: Error: Can't resolve
'./../../../../tmp/app-using-clone.AIFQnn/buffer' in
'/usr/share/nodejs/clone'
 @ /usr/share/nodejs/clone/clone.js 1:0-58
 @ ./source/main.js

$
=====


-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 5.6.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_AU.UTF-8), LANGUAGE=en_AU.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_AU.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages webpack depends on:
ii  node-ajv                           6.10.2-1
ii  node-ajv-keywords                  3.4.1-1
ii  node-anymatch                      3.1.1+~2.1.1-1
ii  node-debbundle-acorn [node-acorn]  6.2.1+ds+~cs11.24.3-3
ii  node-enhanced-resolve              4.1.0-4
ii  node-esrecurse                     4.2.1-1
ii  node-estraverse                    4.2.0-1
ii  node-findup-sync                   4.0.0-3
ii  node-interpret                     1.0.1-1
ii  node-json-parse-better-errors      1.0.2-2
ii  node-libs-browser                  2.2.1-3
ii  node-loader-runner                 2.3.0-2
ii  node-loader-utils                  1.2.3-1
ii  node-memory-fs                     0.4.1-2
ii  node-micromatch                    4.0.2+repack-3
ii  node-mkdirp                        0.5.1-2
ii  node-neo-async                     2.6.1-3
ii  node-resolve-cwd                   2.0.0-2
ii  node-schema-utils                  1.0.0-2
ii  node-supports-color                6.1.0-2
ii  node-tapable                       1.0.0-4
ii  node-uglifyjs-webpack-plugin       1.3.0-6
ii  node-watchpack                     1.6.0-2
ii  node-webassemblyjs                 1.9.0+dfsg-4
ii  node-webpack-sources               1.1.0-2
ii  node-yargs                         15.3.0-1
ii  nodejs                             10.20.1~dfsg-1

webpack recommends no packages.

webpack suggests no packages.

-- no debconf information

-- 
 \            “Politics is not the art of the possible. It consists in |
  `\       choosing between the disastrous and the unpalatable.” —John |
_o__)                                    Kenneth Galbraith, 1962-03-02 |
Ben Finney <[email protected]>

Attachment: signature.asc
Description: PGP signature


--- End Message ---
--- Begin Message ---
Control: tags -1 upstream wontfix
Control: summary -1 0

The upstream project provides an insufficiently-documented workaround
to avoid this error behaviour.

On 29-Dec-2020, Jonas Smedegaard wrote:

> Above by Pirate Praveen seems confirmed by this: 
> https://stackoverflow.com/questions/53566238/why-does-webpack-includes-a-buffer-polyfill-by-default

That isn't clear to me (the question assumes I know what a “buffer
polyfill” is, an there is no answer provided). But I'll take your word
for it that Pirate's assertion is supported.

> I.e. in previous releases of webpack a polyfill was included with
> webpack, but with newer releases the user needs to decide how to
> handle it.
> https://webpack.js.org/migrate/5/#test-webpack-5-compatibility.

Thank you for the link. but it's not very enlightening; it doesn't at
all describe what that configuration option does (only that it's
removed in a later version than what I'm using), and doesn't
immediately apply (Debian doesn't provide Webpack 5 so “test Webpack 5
compatibility” isn't something I would think I need to read for this
issue).

> So understably confusing, but not specific to the Debian package and
> not an upstream bug either but documented behavior

So, with the mystery of the unknown configuration option `node.buffer`
before me, I try looking up the relevant documentation for Webpack 4
instead.

That configuration option has absolutely no description.
<URL:https://v4.webpack.js.org/configuration/node/#nodebuffer>.

I maintain that this isn't appropriately documented, because the
configuration option is not discoverable by searching for the error
message, and even when I do reach the documentation for that
configuration option, it gives no description at all.

On the assumption this will not result in any change from either the
upstream project or the Debian package, I'll go ahead and close this
bug report.

Thank you for your help. I think it's quite fair to characterise this
as an upstream bug, one that is both undocumented behaviour and should
not produce the error that it does. I would not hesitate to report a
bug like this again in future.

-- 
 \     “You know what would make a good story? Something about a clown |
  `\    who makes people happy, but inside he's real sad. Also, he has |
_o__)                                   severe diarrhea.” —Jack Handey |
Ben Finney <[email protected]>

Attachment: signature.asc
Description: PGP signature


--- End Message ---
-- 
Pkg-javascript-devel mailing list
[email protected]
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Reply via email to