Final 4.0 release #1903

gauravtiwari · 2019-01-21T12:38:38Z

Sorry, it took a while and thanks for the support.

Could everyone please give the latest RC a try and see if everything works as needed? If no major issues found, I will go ahead a make a 4.0 stable release today.

Thank you 🙏

mayordwells · 2019-01-21T15:48:06Z

Hi @gauravtiwari
Don't know why my project fails to compile after upgrading.

Here's my package.json file

{
  "name": "conectar",
  "private": true,
  "scripts": {
    "db:setup": "docker-compose run --rm web rails db:drop db:create db:migrate db:seed",
    "lint": "yarn run esw --ext .js --ext .jsx app/javascript --watch",
    "lint:fix": "yarn run esw --ext .js --ext .jsx app/javascript --fix",
    "bundle-stats": "NODE_ENV=development ./bin/webpack --config config/webpack/development.js --profile --json > public/packs/stats.json",
    "bundle-analyze": "node_modules/.bin/webpack-bundle-analyzer public/packs/stats.json"
  },
  "dependencies": {
    "@babel/core": "^7.2.2",
    "@babel/plugin-proposal-class-properties": "^7.2.3",
    "@babel/plugin-syntax-dynamic-import": "^7.2.0",
    "@babel/preset-env": "^7.2.3",
    "@babel/preset-react": "^7.0.0",
    "@rails/webpacker": "https://github.com/rails/webpacker",
    "actioncable": "^5.2.2",
    "axios": "^0.18.0",
    "babel-loader": "^8.0.5",
    "babel-plugin-transform-react-remove-prop-types": "^0.4.23",
    "conectar-ws": "^0.0.9",
    "cookiesjs": "^3.0.3",
    "emoji-mart": "^2.9.2",
    "jwt-decode": "^2.2.0",
    "lodash.flatten": "^4.4.0",
    "moment": "^2.23.0",
    "node-sass": "4.11.0",
    "pimg": "^1.1.3",
    "postcss-cssnext": "^3.1.0",
    "prop-types": "^15.6.2",
    "react": "^16.7.0",
    "react-accessible-accordion": "^2.4.5",
    "react-actioncable-provider": "^2.0.0",
    "react-activestorage-provider": "^0.7.0",
    "react-big-calendar": "^0.20.3",
    "react-dom": "^16.7.0",
    "react-infinite-scroll-component": "^4.3.0",
    "react-redux": "^6.0.0",
    "react-responsive-carousel": "^3.1.45",
    "react-router-dom": "^4.3.1",
    "react-router-transition": "^1.2.1",
    "react-transition-group": "^2.5.3",
    "redux": "^4.0.1",
    "redux-thunk": "^2.3.0",
    "semantic-ui-react": "^0.84.0",
    "sweetalert": "^2.1.2",
    "uuid": "^3.3.2",
    "webpack-cli": "^3.1.2",
    "webpack-dev-server": "^3.1.14"
  },
  "devDependencies": {
    "babel-eslint": "^10.0.1",
    "concurrently": "^4.1.0",
    "eslint": "^5.12.1",
    "eslint-config-prettier": "^3.6.0",
    "eslint-plugin-prettier": "^3.0.1",
    "eslint-plugin-react": "^7.12.4",
    "eslint-watch": "^4.0.2",
    "prettier": "^1.16.0",
    "webpack-bundle-analyzer": "^3.0.3"
  }
}

And here's a screenshot of the error

And my entry file looks like this:

// Main js file
import React from 'react';
import { render } from 'react-dom';
import ActionCable from 'actioncable';
import { ActionCableProvider } from 'react-actioncable-provider';

import App from '../src/components';

document.addEventListener('DOMContentLoaded', async () => {

  const cable = ActionCable.createConsumer(WS_ROOT);

  render(
    <ActionCableProvider cable={cable}>
      <App />
    </ActionCableProvider>,
    document.getElementById('root')
  );
});

Take note, it also didn't work when I removed ActionCableProvider from the app wrapper.

I also ran this command to add latest code from new release bundle exec rails webpacker:install

What could be the src of this problem?

jasl · 2019-01-21T16:03:20Z

Hi, could you look #1887 ?

mayordwells · 2019-01-21T16:06:17Z

Hi, @jasl seems that's not the problem.
Okay, I think I found the src of the problem. After upgrading to rc5 and installing the following changes were made to babel.config.js

I had to return it back to how it was, except the currentEnv on this line - JSON.stringify(currentEnv)

Then everything seems to be working after that, at least it compiled successfully. But my screen remains blank after that.

Not sure if this is a problem with webpacker though. Going to try to debug further.

gauravtiwari · 2019-01-21T16:06:23Z

@mayordwells

I think a simple upgrade path would be:

Create a backup (if you have made changes to config/webpack -> config/webpack_old)
Re-run all the installers you have run in the beginning, webpacker:install and webpacker:install:react
Copy any plugins and presets from .babelrc to babel.config.js, same for .postcssrcyml to postcss.config.js (only if you have added custom ones)
Delete old .babelrc and .postcssrc.yml
bundle exec rake app:update:bin (optional but just in case they are changed)
Re-run ./bin/webpack-dev-server

mayordwells · 2019-01-21T16:10:12Z

@gauravtiwari good evening, pls check my comment above.

jasl · 2019-01-21T16:10:51Z

Hi, @jasl seems that's not the problem.
Okay, I think I found the src of the problem. After upgrading to rc5 and installing the following changes were made to babel.config.js

I had to return it back to how it was, except the currentEnv on this line - JSON.stringify(currentEnv)

Then everything seems to be working after that, at least it compiled successfully. But my screen remains blank after that.

Not sure if this is a problem with webpacker though. Going to try to debug further.

I can reproduce on new app (Rails 6 alpha + Webpacker 4 RC3) twice, now I do a quick check again, if problem still here, I'll given a public repo

mayordwells · 2019-01-21T16:13:22Z

@jasl check there's a RC5 already 😀

gauravtiwari · 2019-01-21T16:22:36Z

@mayordwells Sorry, app:update:bin please

jasl · 2019-01-21T16:33:20Z

@mayordwells @gauravtiwari reproduced on Rails 6 beta + Webpacker 4 RC5

I push a PoC at https://github.com/jasl/test_webpacker4

mayordwells · 2019-01-21T17:45:26Z

@gauravtiwari okay after few hours of debugging, I found out that the gem is the cause of the blank screen - gem 'webpacker', '>= 4.0.0.rc.5'

I have reverted back to rc.2 in the mean time.

gauravtiwari · 2019-01-21T17:46:45Z

Hmm, that's strange. Are you using split chunks? How are you using pack tag helpers?

mayordwells · 2019-01-21T18:00:22Z

@gauravtiwari To be honest, I don't fully understand the meaning of split chunks, but I have it in webpack/environment.js like so environment.splitChunks();

This is how I'm using pack tag helpers -

= stylesheet_pack_tag 'application', 'data-turbolinks-track': 'reload'
= javascript_pack_tag 'application', 'data-turbolinks-track': 'reload'

gauravtiwari · 2019-01-21T18:02:36Z

You would need to use new chunks helper if you are enabling split chunks. Otherwise, you can disable environment.splitChunks() by deleting the line and regular pack tag should work fine.

gauravtiwari · 2019-01-21T18:03:03Z

See changelog: https://github.com/rails/webpacker/blob/master/CHANGELOG.md#400rc4---2019-01-21

mayordwells · 2019-01-21T18:27:49Z

@gauravtiwari so you are right after removing environment.splitChunks() rc5 worked. But then I thought to use those tags *_packs_with_chunks_tag for test and activated back split chunks.

Got the following error:

We are currently using React Suspense and Lazy for lazy loading pages on the frontend. Here's an example of our webpack log during compilation. BTW this is generated without environment.splitChunks()

Could this be the reason for the error "duplicated mapping key"?

gauravtiwari · 2019-01-21T18:29:47Z

That seems like some issue in webpacker.yml. Could you please double check if there is no duplicate key there?

mayordwells · 2019-01-21T18:39:47Z

@gauravtiwari Same error, split chunks activated with environment.splitChunks()
Loading packs with - = stylesheet_packs_with_chunks_tag 'application', 'map', 'data-turbolinks-track': 'reload'
and
= javascript_packs_with_chunks_tag 'application', 'map', 'data-turbolinks-track': 'reload'

Check this gist to see my webpacker.yml

https://gist.github.com/mayordwells/4c3ddb05290b68bfe69dcc7a60ea5631

gauravtiwari · 2019-01-21T18:43:04Z

@mayordwells Is there a pack called map 'application', 'map'? Just application, which is the pack name should be fine.

mayordwells · 2019-01-21T18:43:06Z

@gauravtiwari oh wow you were right, its from the webpacker.yml file

my staging config was like this

  staging:
  <<: *default
  compile: false
  # extract_css: true
  cache_manifest: true

fixed it to be like this

staging:
  <<: *default
  compile: false
  # extract_css: true
  cache_manifest: true

gauravtiwari · 2019-01-21T18:43:10Z

When this error happens?

gauravtiwari · 2019-01-21T18:44:00Z

Great 👍 http://www.yamllint.com/ (good linter)

mayordwells · 2019-01-21T18:44:10Z

Now back to this error again:

mayordwells · 2019-01-21T18:44:22Z

http://www.yamllint.com/

Thanks.

gauravtiwari · 2019-01-21T18:45:08Z

Did you run the react installer? Also, removed .babelrc?

gauravtiwari · 2019-01-21T18:46:14Z

Should contain all react specific packages? https://github.com/rails/webpacker/blob/master/lib/install/examples/react/babel.config.js

mayordwells · 2019-01-21T18:51:55Z

Did you run the react installer? Also, removed .babelrc?

yes I did, since the last time I upgraded to rc2.

It compiles after removing this.

Here's my config right now:

module.exports = function(api) {
  var validEnv = ['development', 'test', 'production']
  var currentEnv = api.env()
  var isDevelopmentEnv = api.env('development')
  var isProductionEnv = api.env('production')
  var isTestEnv = api.env('test')

  if (!validEnv.includes(currentEnv)) {
    throw new Error(
      'Please specify a valid `NODE_ENV` or ' +
        '`BABEL_ENV` environment variables. Valid values are "development", ' +
        '"test", and "production". Instead, received: ' +
        JSON.stringify(currentEnv) +
        '.'
    )
  }

  return {
    presets: [
      isTestEnv && [
        require('@babel/preset-env').default,
        {
          targets: {
            node: 'current'
          }
        }
      ],
      (isProductionEnv || isDevelopmentEnv) && [
        require('@babel/preset-env').default,
        {
          forceAllTransforms: true,
          useBuiltIns: 'entry',
          modules: false,
          exclude: ['transform-typeof-symbol']
        }
      ],
      [
        require('@babel/preset-react').default,
        {
          development: isDevelopmentEnv || isTestEnv,
          useBuiltIns: true
        }
      ]
    ].filter(Boolean),
    plugins: [
      require('babel-plugin-macros'),
      require('@babel/plugin-syntax-dynamic-import').default,
      isTestEnv && require('babel-plugin-dynamic-import-node'),
      require('@babel/plugin-transform-destructuring').default,
      [
        require('@babel/plugin-proposal-class-properties').default,
        {
          loose: true
        }
      ],
      [
        require('@babel/plugin-proposal-object-rest-spread').default,
        {
          useBuiltIns: true
        }
      ],
      [
        require('@babel/plugin-transform-runtime').default,
        {
          helpers: false,
          regenerator: true
        }
      ],
      [
        require('@babel/plugin-transform-regenerator').default,
        {
          async: false
        }
      ],
      isProductionEnv && [
        require('babel-plugin-transform-react-remove-prop-types').default,
        {
          removeImport: true
        }
      ]
    ].filter(Boolean)
  }
}

And now the home page looks like this:

gauravtiwari · 2019-01-21T18:53:52Z

Ahh, yes, it's an old babel config, which has a typo we fixed later.

Yes, because you are including map in the chunks_tag, please remove (guess you copied from the changelog). That helper tag takes an array, but in your case since it's just one pack - application.

gauravtiwari · 2019-01-21T18:54:20Z

javascript_packs_with_chunks_tag 'application', 'data-turbolinks-track': 'reload'

mayordwells · 2019-01-21T18:54:41Z

javascript_packs_with_chunks_tag 'application', 'data-turbolinks-track': 'reload'

Okay going to try this now. Thanks.

gauravtiwari · 2019-01-21T18:55:19Z

Same for stylesheets tag too.

jakeNiemiec · 2019-02-18T19:47:56Z

@connorshea The change was made for #1887 to enable webpacker to pack user avatars via JavaScript.

IMHO, this is not a valid reason to break deploys for all Heroku users. The fix didn't even seem to help the original user who made the issue, and has since caused more issues than it fixed: #1938 (comment) #1845 (comment) #1915 #1947 #1922 (comment).

Beyond that, why would you want your client-side JS to handle all of your image loading? Just toss your image in /public, why make your builds longer than they need to be?

I'd prefer we release 4.0.0 and then fix these problems in 4.x over the next few weeks/months rather than delaying the release any more than it needs to be.

3 months ago, Webpack@5 had their first alpha release. There seems to be a bunch of breaking structural changes. I really think that webpackER needs to focus more on core use-cases (i.e. webpacking JS) and not trying to fill the entirety of Sprokets' shoes.

Edit: As I said on the mailing list, filling Sprokets' shoes is not a bad thing, it is just a very large scope with many user-specific caveats.

connorshea · 2019-02-18T20:18:14Z

@jakeNiemiec having read through the issues linked I can't say I fully understand the issue or why the given change was chosen as the solution, so I could be wrong, but from my current understand of the situation I do agree now that that's an issue that needs to be fixed before 4.0 final is released. Breaking deploys on Heroku isn't an acceptable trade-off.

Given that, what would the ideal solution be? Just revert the change entirely?

gaffneyc · 2019-02-18T20:58:51Z

I've opened #1950 that reverts the pull request. I'm not sure if it's a complete fix but it seems a necessary start.

jakeNiemiec · 2019-02-18T22:01:19Z

@connorshea ~~My understanding is that it comes down to 2 restrictions: ~~

webpacker/CHANGELOG.md

Line 7 in 771e3b1

- Remove `context` from file loader in favour of simpler paths

webpacker/CHANGELOG.md

Line 19 in 771e3b1

- Namespaces for compiled packs in the public directory

~~These changes don't seem to be configurablemake for poor defaults and violate some vanilla webpack conventions. Other issues:~~

~~files will be copied to /public during compilation (with different hashes suffixed) but only one gets referenced in manifest.json~~
~~users who use CDNs can no longer use source_path to pass the CDN context for assets~~
~~@gauravtiwari labeled this issue as won't fix without further communication to explain why~~

This section has since been addressed.

As @joelmoss points out, "the default Webpack config that Webpacker produces is now ways away from what I need in my projects.". These changes & the 4.0 delay make a good case to just use vanilla webpack. Need a weird config for your CDN? The base API has whatever you need covered without requiring you to peel back or translate layers of API abstraction.

But how hard is it to use webpack without webpackER?

Follow the Getting Started with Webpack guide
Use the webpack-assets-manifest plugin to generate a manifest.json during a build (just like webpackER does)
Load the generated manifest.json file into a hash
use the paths within the hash to generate the desired content_tags
Feel the weight lifted from your chest. Got webpack errors? Most common vanilla webpack pitfalls are well documented on StackOverflow and in GH issues.

Caveats:

use webpack instead bin/webpack (may need to run yarn global add webpack to use with cli, outside of yarn run)
webpack-dev-server requires a bit more work involving polling for https://localhost:8081/manifest.json and setting up a proxy for Hot reloading.
depending on how you are loading your css with webpack-dev-server, you might need to only create a <link> when the dev server is not running. (e.g. if you use style-loader)
feel free to email me if you get stuck while implementing this

If this does not sound appealing or if webpacker is working well for you, I wouldn't recommend following this. But if you are having problems and want to experience life without webpackER abstractions, consider this a dirty eject.

Edit: I found a note on how to solve part of the problem, but it does not address the file overwriting from #1887 (comment)

joelmoss · 2019-02-19T09:03:17Z

However, I am still pursuing my path of a lighter and [almost] webpack only solution, with only the required integration with Rails.

If all goes well, I will of course open source it.

jaredbeck · 2019-02-20T01:26:15Z

Looking forward to using babel 7 because prominent projects like jest no longer support babel 6, not even for security issues. Thanks to everyone working on this release. ❤️

nrako · 2019-02-21T16:15:20Z

@joelmoss – this sounds like music to my ears! I'm looking forward to it, please let us know if we can help, at least I would.

maschwenk · 2019-02-21T20:40:32Z

Anyone have opinions on this? #1946

Pretty much a 4.0 blocker for anyone using resolved_paths....but it's resolved_paths so I guess a followup bugfix release could suffice 😬

007lva · 2019-02-25T09:25:24Z

At www.rankia.com we use resolved_paths and indeed we need #1946 to upgrade.

maschwenk · 2019-02-27T17:32:27Z

@007lva #1946 is merged! thanks @javan

007lva · 2019-02-27T21:48:36Z

@maschwenk @javan Thank you!

gauravtiwari · 2019-03-03T16:30:09Z

Hello everyone, I was away on holiday. I will look into pending PRs now and see if we can make a release. Apologies for the delay.

gauravtiwari · 2019-03-03T19:02:26Z

Almost ready, two PRS to the final release 🎉 #1974 #1973

gauravtiwari · 2019-03-03T21:18:08Z

Please try out latest RC.

gauravtiwari · 2019-03-04T09:41:08Z

If everything looks good then I am happy to make a stable release today?

connorshea · 2019-03-04T15:22:23Z

My test suite is passing on rc8 and everything looks good after a quick check. Not a comprehensive check, but it looks good to me :)

lucaong · 2019-03-04T15:23:27Z

We are also running rc8 in production since this morning. No issue so far.

maschwenk · 2019-03-04T17:47:44Z

👍 my resolved_paths change went in and seems to be working 😄

gauravtiwari · 2019-03-04T17:57:52Z

Stable 4.0 released

connorshea · 2019-03-04T18:01:44Z

Time to update the rails/rails Gemfile with the 4.0 stable release instead of the rc? :D And probably elsewhere in the repo where webpacker is used.

jaredbeck · 2019-03-04T19:56:53Z

To update a Webpacker v3.5 app to v4, see v4-upgrade.md. If you're using React, look for "Package-Specific Notes".

This was referenced Feb 19, 2019

Is enabling full source maps in production a wise default? #769

Closed

Compiling takes ~50s in development #1948

Closed

jaredbeck mentioned this issue Feb 20, 2019

ReDOS on micromatch/braces (reported on Feb 15th 2019) jestjs/jest#7917

Closed

jakeNiemiec mentioned this issue Feb 26, 2019

Revert "Remove context from file loader (#1914)" #1950

Closed

gauravtiwari closed this as completed Mar 4, 2019

sharang-d mentioned this issue Mar 8, 2019

Use the latest stable release of webpacker rails/rails#35538

Merged

db0sch mentioned this issue Mar 9, 2019

Webpacker 4.0 issue with Babel and CSS lewagon/rails-templates#78

Closed

jakeNiemiec mentioned this issue May 21, 2019

MissingEntryError with javascript_packs_with_chunks_tag but not with javascript_pack_tag #1967

Closed

jakeNiemiec mentioned this issue Nov 4, 2019

How to use webpack-dev-server not managed by webpacker/Rails? #2348

Closed

Final 4.0 release #1903

Final 4.0 release #1903

Comments

gauravtiwari commented Jan 21, 2019

mayordwells commented Jan 21, 2019 • edited Loading

jasl commented Jan 21, 2019

mayordwells commented Jan 21, 2019

gauravtiwari commented Jan 21, 2019 • edited Loading

mayordwells commented Jan 21, 2019

jasl commented Jan 21, 2019

mayordwells commented Jan 21, 2019

gauravtiwari commented Jan 21, 2019

jasl commented Jan 21, 2019

mayordwells commented Jan 21, 2019

gauravtiwari commented Jan 21, 2019

mayordwells commented Jan 21, 2019 • edited Loading

gauravtiwari commented Jan 21, 2019

gauravtiwari commented Jan 21, 2019

mayordwells commented Jan 21, 2019 • edited Loading

gauravtiwari commented Jan 21, 2019

mayordwells commented Jan 21, 2019

gauravtiwari commented Jan 21, 2019

mayordwells commented Jan 21, 2019

gauravtiwari commented Jan 21, 2019

gauravtiwari commented Jan 21, 2019

mayordwells commented Jan 21, 2019

mayordwells commented Jan 21, 2019

gauravtiwari commented Jan 21, 2019

gauravtiwari commented Jan 21, 2019

mayordwells commented Jan 21, 2019

gauravtiwari commented Jan 21, 2019 • edited Loading

gauravtiwari commented Jan 21, 2019

mayordwells commented Jan 21, 2019

gauravtiwari commented Jan 21, 2019

jakeNiemiec commented Feb 18, 2019 • edited Loading

connorshea commented Feb 18, 2019

gaffneyc commented Feb 18, 2019

jakeNiemiec commented Feb 18, 2019 • edited Loading

joelmoss commented Feb 19, 2019

jaredbeck commented Feb 20, 2019

nrako commented Feb 21, 2019

maschwenk commented Feb 21, 2019 • edited Loading

007lva commented Feb 25, 2019

maschwenk commented Feb 27, 2019

007lva commented Feb 27, 2019

gauravtiwari commented Mar 3, 2019

gauravtiwari commented Mar 3, 2019

gauravtiwari commented Mar 3, 2019

gauravtiwari commented Mar 4, 2019

connorshea commented Mar 4, 2019

lucaong commented Mar 4, 2019

maschwenk commented Mar 4, 2019

gauravtiwari commented Mar 4, 2019

connorshea commented Mar 4, 2019

jaredbeck commented Mar 4, 2019

mayordwells commented Jan 21, 2019 •

edited

Loading

gauravtiwari commented Jan 21, 2019 •

edited

Loading

mayordwells commented Jan 21, 2019 •

edited

Loading

mayordwells commented Jan 21, 2019 •

edited

Loading

gauravtiwari commented Jan 21, 2019 •

edited

Loading

jakeNiemiec commented Feb 18, 2019 •

edited

Loading

jakeNiemiec commented Feb 18, 2019 •

edited

Loading

maschwenk commented Feb 21, 2019 •

edited

Loading