Bug#958780: [Pkg-javascript-devel] Bug#958780: do we really want to do this ?
On Thu, Apr 30, 2020 at 6:57 pm, Paolo Greppi
wrote:
see below ...
Il 30/04/20 18:10, Pirate Praveen ha scritto:
...
I have pushed my changes to babel7 branch and the error I get is,
gulp build
[15:53:07] Local gulp not found in /<>
[15:53:07] Try running: npm install gulp
[15:53:07] Using globally installed gulp
[15:53:07] Using gulpfile /<>/gulpfile.js
[15:53:07] Starting 'build'...
[15:53:13] Finished 'build' after 6.18 s
node ./scripts/build-webpack.js
Unhandled rejection TypeError: fileDependencies.map is not a
function
at compiler.run
(/<>/scripts/build-webpack.js:118:38)
...
If you get that, it means webpack failed.
The confusing error is because the stats data structure of our
webpack (4.30.0) is not compatible with the webpack they expect
(2.7.0).
To actually see the errors, tweak the compiler.run callback like this:
compiler.run((err, stats) => {
var stringify = require('json-stringify-safe');
console.log(stringify(stats, null, 2));
});
I attach the JSON it prints. Sample extract:
"error": {
"origin": null,
"dependencies": null,
"module": "[Circular ~.compilation.entries.0]",
"name": "ModuleBuildError",
"error": {
"code": "BABEL_VERSION_UNSUPPORTED",
"version": "6.26.0",
"range": "^7.0.0-0"
}
}
I think it would be easier to embed gulp-babel 7.x in node-yarnpkg
until we can update babel-loader also.
Bug#958780: [Pkg-javascript-devel] Bug#958780: do we really want to do this ?
On Sun, Apr 26, 2020 at 4:33 pm, Paolo Greppi wrote: My understanding is that node-gulp-babel v8 should be used with babel7. Same goes for node-babel-loader, you need v8 for babel7, but we only have node-babel-loader 7 in Debian. If we want babel6 to co-exist with babel7, then we don't want to just update node-gulp-babel and node-babel-loader to v8. We want to keep node-gulp-babel and node-babel-loader at v7 for compatibility with babel6, and upload new node-gulp-babel8 and node-babel-loader8 for babel7. Back to the topic of this bug, do we really want to upgrade the yarn build system from babel6 to babel7 ? Here is some indication that upstream is not interested: https://github.com/yarnpkg/yarn/pull/6322 But I have raised the issue anyway: https://github.com/yarnpkg/yarn/issues/8083 I was able to build part of node-yarnpkg with babel7 (the part that uses gulp-babel). Since babel 7 does not need babel-loader 8.x right now (gulp-babel and rollup-plugin-babel are build dependencies of babel 7 and has to go together to unstable) we could continue using babel-loader 7.x that works with babel 6 (so node-yarnpkg will be using both babel 7 and babel 6). babel-loader 7 -> 8 transition will need to be handled later. I have pushed my changes to babel7 branch and the error I get is, gulp build [15:53:07] Local gulp not found in /<> [15:53:07] Try running: npm install gulp [15:53:07] Using globally installed gulp [15:53:07] Using gulpfile /<>/gulpfile.js [15:53:07] Starting 'build'... [15:53:13] Finished 'build' after 6.18 s node ./scripts/build-webpack.js Unhandled rejection TypeError: fileDependencies.map is not a function at compiler.run (/<>/scripts/build-webpack.js:118:38) at finalCallback (/usr/share/nodejs/webpack/lib/Compiler.js:220:39) at hooks.done.callAsync.err (/usr/share/nodejs/webpack/lib/Compiler.js:236:13) at AsyncSeriesHook.eval [as callAsync] (eval at create (/usr/share/nodejs/tapable/lib/HookCodeFactory.js:24:12), :6:1) at AsyncSeriesHook.lazyCompileHook [as _callAsync] (/usr/share/nodejs/tapable/lib/Hook.js:35:21) at onCompiled (/usr/share/nodejs/webpack/lib/Compiler.js:234:21) at hooks.afterCompile.callAsync.err (/usr/share/nodejs/webpack/lib/Compiler.js:631:15) at AsyncSeriesHook.eval [as callAsync] (eval at create (/usr/share/nodejs/tapable/lib/HookCodeFactory.js:24:12), :6:1) at AsyncSeriesHook.lazyCompileHook [as _callAsync] (/usr/share/nodejs/tapable/lib/Hook.js:35:21) at compilation.seal.err (/usr/share/nodejs/webpack/lib/Compiler.js:628:31) at AsyncSeriesHook.eval [as callAsync] (eval at create (/usr/share/nodejs/tapable/lib/HookCodeFactory.js:24:12), :6:1) at AsyncSeriesHook.lazyCompileHook [as _callAsync] (/usr/share/nodejs/tapable/lib/Hook.js:35:21) at hooks.optimizeAssets.callAsync.err (/usr/share/nodejs/webpack/lib/Compilation.js:1329:35) at AsyncSeriesHook.eval [as callAsync] (eval at create (/usr/share/nodejs/tapable/lib/HookCodeFactory.js:24:12), :6:1) at AsyncSeriesHook.lazyCompileHook [as _callAsync] (/usr/share/nodejs/tapable/lib/Hook.js:35:21) at hooks.optimizeChunkAssets.callAsync.err (/usr/share/nodejs/webpack/lib/Compilation.js:1320:32)
Bug#958780: [Pkg-javascript-devel] Bug#958780: do we really want to do this ?
On Sun, Apr 26, 2020 at 4:33 pm, Paolo Greppi wrote: My understanding is that node-gulp-babel v8 should be used with babel7. Same goes for node-babel-loader, you need v8 for babel7, but we only have node-babel-loader 7 in Debian. If we want babel6 to co-exist with babel7, then we don't want to just update node-gulp-babel and node-babel-loader to v8. We want to keep node-gulp-babel and node-babel-loader at v7 for compatibility with babel6, and upload new node-gulp-babel8 and node-babel-loader8 for babel7. My suggestion, 1. node-rollup-plugin-babel: Plan A, update all packages build depending on node-rollup-plugin-babel to build with babel 7 (psl.js updated already and seems pretty straight forward). Plan B, embed rollup-plugin-babel 4 in node-babel7 if plan A becomes too difficult. 2. node-gulp-babel: Plan A, update all packages build depending on node-gulp-babel to babel 7. Plan B: embed gulp-babel 8 in node-babel 7 as it seems a simple module unlike rollup-plugin-babel. 3. babel-loader: This is not a blocker as node-babel7 build depends on node-rollup-plugin-babel and node-gulp-babel only. Lets use https://wiki.debian.org/Javascript/Nodejs/Transitions/Babel7 to track the status. Back to the topic of this bug, do we really want to upgrade the yarn build system from babel6 to babel7 ? Here is some indication that upstream is not interested: https://github.com/yarnpkg/yarn/pull/6322 But I have raised the issue anyway: https://github.com/yarnpkg/yarn/issues/8083 Ideally we should have only one version of babel in bullseye and we should try to get rid of babel 6 by bullseye freeze. Even if upstream is not interested, we will have to maintain the patch.
Bug#958780: do we really want to do this ?
My understanding is that node-gulp-babel v8 should be used with babel7. Same goes for node-babel-loader, you need v8 for babel7, but we only have node-babel-loader 7 in Debian. If we want babel6 to co-exist with babel7, then we don't want to just update node-gulp-babel and node-babel-loader to v8. We want to keep node-gulp-babel and node-babel-loader at v7 for compatibility with babel6, and upload new node-gulp-babel8 and node-babel-loader8 for babel7. Back to the topic of this bug, do we really want to upgrade the yarn build system from babel6 to babel7 ? Here is some indication that upstream is not interested: https://github.com/yarnpkg/yarn/pull/6322 But I have raised the issue anyway: https://github.com/yarnpkg/yarn/issues/8083 Paolo
