Investigate and resolve component styling issues in entrypoints

[braughtg]

When multiple entry points in a module use a component that has a <style scoped> block Vite splits the CSS into its own file. This then requires that Drupal be told about that file in the <module>.libraries.yml file in the css: section. Note that if only one entry point in the module uses the component then the css is bundled into that entry point's css and everything is fine without adding it to the libraries.yml file. That said, there seems to be no harm in including the component's .css file in the libraries.yml even if only one component uses it (though there may be errors getting logged somewhere in drupal???).

Need to develop a consistent way of handling this and documenting it so that when it goes wrong (and I'm sure it will) there is at least something to refer to.

Also related, it appears that all of the .css in the <module>.libraries.yml file can go under the component: heading instead of including one under the theme: heading. Should probably check on what the difference is there. If this is the way to go then the templates for the entry point should also be updated (related to #189)

This should all be fixed retroactively for all of the entry points thus far.

[braughtg]

The above description does not seem to be quite accurate. For example, the SubmitResetButtons component has its own <style scoped> blog and is used in multiple entry points but is not packaged into its own .css file. The result is that the buttons are not actually styled using the <style scoped> styles when the buttons are rendered in an entry point. This is something that will need to be better understood. This will relate to #219 also.

[braughtg]

Here are a few links that might be useful in tracking down a solution to this:

This seems too simple but maybe ...

• https://github.com/vitejs/vite/issues/1579#issuecomment-1475411735

These two look pretty good:

• https://www.npmjs.com/package/vite-plugin-lib-inject-css
• https://www.npmjs.com/package/vite-plugin-css-injected-by-js

Some others...

• https://github.com/vitejs/vite/issues/1579
• https://github.com/wxsms/vite-plugin-libcss
• https://vitejs.dev/guide/build.html#library-mode
• https://www.npmjs.com/package/@senojs/rollup-plugin-style-inject

[braughtg]

Using cssCodeSplit: false in the vite build will not work. This adds the css to the .js file, but that file is pulled into the drupal page in the body so the css is not recognized. Similarly none of the injected styles will work. either.

Seems like the only path forward is to ensure that every component that has <style scoped> gets a .css file generated for it and that that file is included in the *.libraries.yml file for the drupal module.

[braughtg]

May need to build in lib mode and include an entry point for each entry point and each component and each library. Possibly adapt the following:

 build: {
    lib: {
      format: ['es'],
      entry: {
        index: 'src/index.ts',
        button: 'src/components/button/index.ts',
        select: 'src/components/select/index.ts',
      },
    }
    rollupOptions: {
      output: {
        // Put chunk files at <output>/chunks
        chunkFileNames: 'chunks/[name].[hash].js',
        // Put chunk styles at <output>/assets
        assetFileNames: 'assets/[name][extname]',
        entryFileNames: '[name].js',
      },
    },
  }

This would require generating the entry piece programmatically from the component, entrypoints and libraries directories.

This doesn't seem to be working out well.

[braughtg]

Also noticed that the build for fd2 places some bits of code and css into uiUtil.js and uiUtil.css. These seem to be bits taken from some of the components. It is not at all clear why this code is going into those files rather than into a file associated with the component. Maybe figuring that out will present an answer?

[braughtg]

Also noticed that the build for fd2 places some bits of code and css into uiUtil.js and uiUtil.css. These seem to be bits taken from some of the components. It is not at all clear why this code is going into those files rather than into a file associated with the component. Maybe figuring that out will present an answer?

If the uiUtil.css file is added to the Drupal libraries (*.libraries.yml) then the styling that was moved there is applied.

This works, but is unsatisfying because the *.libraries.yml file will have to be customized for each entry point because it may need a .css that was separated out (e.g. CropSelector or SoilDisturbance) or not.

A few thoughts here:

• Maybe we can get all the css into a single flie and then put that in *.libraries.css
• Maybe we can use the drupal controller and add all the libraries dynamically?

[braughtg]

• Maybe we can get all the css into a single flie and then put that in *.libraries.css

Setting build.cssCodeSplit: false in the vite.config.js file causes all of the css to be placed into style/style.css.

So if that file is then included in the *libraries.yml for all of the entry points things should be good to go.

[braughtg]

Proposed Solution:

• [x] - modify vite.config.js files (fd2, examples, school) to
  • include build.cssCodeSplit: false
  • This will cause a single style/style.css file to be built with the css for the whole module.
  • remove the build.exclude since it is not having any effect.
  • replace the complex assetFileNames logic withassetFileNames: '[name]/[name].[ext]',`
• [x] - modify existing *.libraries.yml files (fd2, examples, school) to
  • add style/style.css to the entry points as component
  • remove all of the currently existing style imports.
• [x] - modify the template for libraries.yml to attach just the style/style.css file as component to future entry points.