Add CLI command to update webpack config

[ayushn21]

This is a 🙋 feature or enhancement.

Summary

Adds a CLI command invoked with bridgetown webpack to manipulate a site's webpack config.

To allow us to upgrade configurations easily without overwriting our users' customizations, I've split the config into two files.

One (webpack.defaults.js) is controlled by us that shouldn't be edited by the user. The actual webpack.config.js which is used by webpack just loads the former and allows the user to override our default config options.

This way when we update the file, it won't overwrite user customizations and hopefully won't break their configs!

The 3 options available for this command are:

• setup: Copies the webpack files into place
• update: Updates the webpack.defaults.js file to the version contained in the bridgetown gem.
• enable-postcss: Creates an empty postcss.config.js and swaps the sass-loader for the postcss-loader in webpack.defaults.js.

I haven't added an option to go from PostCSS to Sass as I don't think there's much of a need for it. From my point of view, I reckon more people would be converting from Sass to PostCSS than the other way round (especially since earlier versions of Bridgetown only supported Sass out of the box, and it's still the default option). Totally open to feedback though!

Docs

I've updated the "Command Line Usage" page in the docs with this new command. Since all new projects will have the two webpack files by default which also contain info about the command; I don't think we need to add anything more to the website.

However I reckon it's worth writing a blog post for existing users to upgrade to this new setup which can be easily done by running bridgetown webpack setup.

To Do

• Remove old config file from site template
• Copy over the new config files when a new site is created
• Add comments to the two new config files explaining what they're for to the user
• Add tests
• Add docs
• Some general misc polish
• Fix failing tests

Context

Resolves #250

[jaredcwhite]

Looking at this, definitely feels like the bridgetown.webpack.config.js file would work best as a config/webpack.defaults.js or something like that (related to your discussion point about directory structure).

[jaredcwhite]

Excited to see where this is headed though! 🥳

[ayushn21]

Looking at this, definitely feels like the bridgetown.webpack.config.js file would work best as a config/webpack.defaults.js or something like that (related to your discussion point about directory structure).

Yup for sure. I prefer webpack.defaults.js as a name as well, thanks! I think for this PR it's best to put that file in the root and then we can relocate that file and bridgetown.config.yml to the config folder in a separate PR.

[jaredcwhite]

Sounds good 👍

[ayushn21]

Aaarrrggghh, I'm at my wits end with these tests .... I changed some of the test_new_command tests to not use the output logs in assertions.

Now one of the test_webpack_command tests fails, but ONLY when run with the whole suite and not by itself. 😭

[jaredcwhite]

Now one of the test_webpack_command tests fails, but ONLY when run with the whole suite and not by itself. 😭

Argh, I've run into something similar in the past. Usually it's because there's some kind of state being preserved accidentally between test runs.

I'm fine with scaling back on the command-level testing and testing a few lower-level bits of logic, if you think that will help. I feel like capturing command output and verifying the text is perhaps too dicey.

[ayushn21]

I'm utterly baffled as to why that particular test is failing! Here's what the test does:

• Creates a new site called new-site with Bridgetown::Commands::Base.start(["new", @path])
• Invokes the webpack command to enable postcss as such:

@cmd.inside(@full_path) do
        @cmd.invoke(:webpack, ["enable-postcss"])
end

The webpack command executes an automation to create postcss.config.js and replace webpack.defaults.js. The webpack.defaults.js template uses site.uses_postcss? to ascertain which loader to include. The uses_postcss? method just checks the site.root_dir for the existence of postcss.config.js

The reason the test is failing is that site.uses_postcss? is incorrectly returning false.

When running the full test suite, in this test for some reason, site.root_dir returns /Users/Ayush/Developer/Personal/open_source/bridgetown/bridgetown-core instead of /Users/Ayush/Developer/Personal/open_source/bridgetown/bridgetown-core/new-site.

To make things even more confusing, the webpack.rb has these these methods:

def self.destination_root
  site.root_dir
end

def site
  @site ||= Bridgetown::Site.new(configuration_with_overrides(quiet: true))
end

I put a byebug breakpoint in the enable-postcss automation and ran self.destination_root... this returned: /Users/Ayush/Developer/Personal/open_source/bridgetown/bridgetown-core/new-site

I then ran: site.root_dir ... this returned:
/Users/Ayush/Developer/Personal/open_source/bridgetown/bridgetown-core