Upgrading to webpacker 6.0.0

I decided to give the webpacker 6.0.0 prerelease a try, to get finally rid of python 2.7. I created a new application and then followed the upgrade procedure webpacker/ 6_0_upgrade.md And it did not work.

After a lot of trial+error, I got the idea to put TWO javascript_pack_tag() into the view template, and thereby include “runtime” and “application”. And this now seems to work.

This is a change between 5.2.1 and 6.0.0pre, and it is not mentioned anywhere. I now have read all docs, two times and a third time, and I do not find a hint about what this could be about.

So please, can somebody give me any pointer, links, keyword, whatever where I can read about this scheme, what it is meant to be, and how it is correctly handled?

(Frankly, I am a unix admin, not a javascript developer. If things get explained, I can figure them out - but I am not up-to-date with the fancies.)

1 Like

Next problem: This javascript code:

    export default class ClassicEditor extends ClassicEditorBase {}

results in this error message:

    TypeError: class constructors must be invoked with 'new'

due to this code (in package.json):

    "babel": {
      "presets": [
        "./node_modules/@rails/webpacker/package/babel/preset.js"
      ]
    }

(This did work before the upgrade) Changing the latter code appears to solve the matter:

    "babel": {
      "presets": [
        "@babel/preset-env"
      ]
    }

Concerning the javascript_pack_tag() issue, it seems I have mostly figured it out now. There are a couple of gotchas to avoid:

  1. The precise version of webpacker 6.0.0 in Gemfile must be the exact same as the version in package.json. The docs currently say to use 6.0.0.pre.2 in Gemfile and 6.0.0-beta.5 in package.json, and this is BOGUS. (But understandable as this all is obviousely work-in-progress.)

  2. 6.0.0-pre.2 is OLDER than 6.0.0-beta.5

  3. Somewhere between 5.2.1 and 6.0.0 the webpack code generation has been changed to split the stuff into a “runtime” and “application” file. (The rationale might be to handle multiple entrypoints more easily.)

  4. with 6.0.0-pre.2 a new helper function javascript_packs_with_chunks_tag() is present, and this should grab the pieces properly together. So javascript_pack_tag() must be changed to javascript_packs_with_chunks_tag() for things to work as expected.

  5. later on, with 6.0.0-beta.5 this new helper function has been removed again, and now javascript_pack_tag() does collect the crap together. So this has to be changed back (coming from pre.2) or not changed at all (coming from 5.2.1).

So this makes sense, and might work smoothly when finalized. :slight_smile:

Concerning the babel issue:That file ./node_modules/@rails/webpacker/package/babel/preset.js comes along with webpacker-6.0.0, and appears to be broken.

It seems to be the replacement for the former ./babel.config.js file. If one restores that former file, things do work.

But worse: that file ./node_modules/@rails/webpacker/package/babel/preset.js cannot be changed! I tried to figure out what has changed to introduce the problem, but If one changes the file, changes will be silently ignored.

Now we have caches without end:

  • we have the ./public/packs, where the final javastuff goes as it is spit out of webpack,
  • we have things in ./tmp/cache/assets and ./tmp/cache/webpacker,
  • we have stuff in ~/.yarn and ~/.cache/yarn
  • we have something in /tmp/v8-compile-cache-PID

and probably still some more which I didn’t find yet - it all looks like coming home and finding a freak party has been staged in our living room. :confused: Now you can delete all of these, you can remove spring, you can check all your system processes, you can reboot the machine, and still changes to that babel preset.js are ignored. If you remove it entirely, webpack(er) fails. If you replace it with a hardlink, changes are ignored. If you replace it with a symlink, changes are honored. :crazy_face:

The reason appears to be: there is yet another cache. That one is in ./node_modules/.cache/babel-loader/ and removing that one seems to help. The steering algorithm for that cache is almost certainly crappy.

1 Like

I gave up at about the point where the Rails gem version didn’t match the npm package version.

I am using webpack directly and staying clear of webpacker. Although I try using webpacker for each new, small project It is still my opinion that webpacker adds a layer of ‘fuzz’ on top of webpack, and it’s not worth the bother to sort it out.

.