[bug]: Extensions shouldn't have to tap `specialFeatures` constantly

zetlen commented 4 years ago

Any extension with a React component, or any file that will go into the bundle, has to do this in its intercept: file

targets.of('@magento/pwa-buildpack').tap(features => {
  features[targets.name] = {
    esModules: true,
    cssModules: true
  }
});

This is tedious, because most extensions WILL contain those types of modules. These flags should be set by default for every module.

The specialFeatures target is meant for extensions to flag that they contain certain file types which will be included into the build. Without explicitly including extensions into Webpack rule patterns, they wouldn't be parsed as ES Modules or CSS modules, because Webpack doesn't do that for all node_modules by default. If we made it do that, we'd have extremely slow builds, so we do need to explicitly include extensions.

But we can make the Webpack JS and CSS loaders include all code inside registered extensions and assume it's CSS and JS modules. Then, a lot of that boilerplate can go away.

Possible solutions Implementation notes

This isn't completely trivial because we still need to keep those rules false "by default", for all the hundreds of Node modules. To have them on "by default" you would need to refactor a bit.
BuildBus should have an accessor for the list of all active extensions; it can gather that from its call to pertain.
In getModuleRules(), the hasFlag(foo) method should return all active extension directories by default, only removing one if it has explicitly tapped specialFeatures to set features[targets.name] = { foo: false }
The UpwardIncludePlugin should no longer error if an upward.yml isn't found, it should just move on