Is your feature request related to a problem? Please describe.
Currently, the hash (and thus whether a reinstall/rebuild is needed) is based on a few files, like package-lock.json. However, in our package we often only change the source files (sass) and not the package-lock.json. The assets are not re-built if a developer updates the package, because the hash is still the same.

Describe the solution you'd like
It would be great if a package can provide a list of files (globs) that would all be used to generate the hash. If a file is added, changed or deleted it should generate a new hash and therefore a rebuild should be done.

An option watch which has the default value ['/package.json', '/package-lock.json', '/npm-shrinkwrap.json', '/yarn.lock'] would be great.

In our case, we would set the watch value to ['/package.json', '/package-lock.json', '/src/**/*.sass'].

Describe the bug
When upgrading the local system to "@symfony/webpack-encore": "^1.0.0" (before ^0.33.0) and using verbosity on composer compile-assets -v[vv], then the script will fail with following error:

 Starting process of 'inpsyde/{thats a secret}-theme' using: `yarn encore dev --verbose`...
       yarn run v1.22.10
       $ encore dev --verbose
       
       Running webpack ...
       
       
       [webpack-cli] Error: Unknown option '--verbose'
       info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
       [webpack-cli] Run 'webpack --help' to see available commands and options
       error Command failed with exit code 2.
       
    Failed processing inpsyde/{thats a secret}-theme.
       [webpack-cli] Error: Unknown option '--verbose'
       [webpack-cli] Run 'webpack --help' to see available commands and options
       error Command failed with exit code 2.
    
    failed!

How to reproduce
The problem here is caused by using "@symfony/webpack-encore": "^1.0.0" which relies on newest webpack and webpack CLI:

"./node_modules/.bin/webpack" --version
webpack 5.32.0
webpack-cli 4.6.0
webpack-dev-server 4.0.0-beta.2

It seems that Webpack/Webpack-CLI do not support anymore the --verbose option.

webpack 5.32.0

>"./node_modules/.bin/webpack" --version && "./node_modules/.bin/webpack" --verbose
webpack 5.32.0
webpack-cli 4.6.0
webpack-dev-server 4.0.0-beta.2
[webpack-cli] Error: Unknown option '--verbose'
[webpack-cli] Run 'webpack --help' to see available commands and options

webpack 4.46.0:

> "./node_modules/.bin/webpack" --version && "./node_modules/.bin/webpack" --verbose
4.46.0
D:\Projects\msd-animal-health\gutenberg-dialogs\node_modules\webpack-cli\bin\cli.js:93
                                throw err;
                                ^
/* snip */

Expected behavior
When using webpack >= 5, then we have to use instead of --verbose the --stats=verbose to get the same result as before.

Additional information

• webpack "stats"-configuration - https://webpack.js.org/configuration/stats/

Description of the bug

The documentation specifies that either npm install or yarn install are call however, it is widely known that these calls can result in newer versions of packages being installed that meet the package.json version pattern requirements. It it generally best practice to use npm ci & yarn install --frozen-lockfile to ensure that only the versions specified in the lock files are what is actually installed.

• NPM: https://docs.npmjs.com/cli/v10/commands/npm-ci
• Yarn: https://classic.yarnpkg.com/lang/en/docs/cli/install/

If you need reproducible dependencies, which is usually the case with the continuous integration systems, you should pass --frozen-lockfile flag.

Reproduction instructions

Setup a repository with this package with a minimal configuration and a lock file. Observe that patch releases may automatically be installed that are not what's listed in the lock file.

Expected behavior

When packages are installed they should only be the versions in the lock file.

Environment info

No response

Relevant log output

No response

Additional context

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

In the README I'm reading the composer plugin compile frontend assets and therefore I have a doubt about backend assets.

Since the plugin run yarn or npm scripts which indiscriminately could compile any kind of assets, wouldn't be more clear to remove references to frontend in the README to avoid confusion?

Unless I'm wrong and there's something in the plugin which address the case of backend assets.

Is your feature request related to a problem?

If you don't want to place the Composer Assets Compiler configuration in the main composer.json file, you can put it in a separate assets-compiler.json file in the root directory of the package (see documentation: https://github.com/inpsyde/composer-asset-compiler#configuration-basics). However, you cannot specify a custom config file location. This differs from other much-used Composer plugins like WordPress Translation Downloader or WP Starter which allow specifying a custom config file.

We usually place these config files in a separate folder, e.g. config/, so assets-compiler.json is the only config that is "left" in the root directory.

Describe the desired solution

Similar to WP Starter (see documentation https://github.com/wecodemore/wpstarter/blob/dev/docs/04-WP-Starter-Configuration.md#configuration-in-a-custom-file), it would be great to be able to specify a custom config file different from the standard stand-alone assets-compiler.json file in the project root.

WP Starter's config file check is not complicated and it should be relatively easy to adapt this to Composer Asset Compiler: https://github.com/wecodemore/wpstarter/blob/ce4032f7524a64008794a6829d2e0212c4cbc42a/src/Util/Requirements.php#L189-L226

Describe the alternatives that you have considered

None, keep using assets-compiler.json.

Additional context

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

Hi,
I have a node module (cabuvan-sass) which is behind private bitbucket. I forgot to grant Codeship access. So the build process failed.

Although the build failed, deployer got executed:

If I do understand this correctly, this would mean it could happen I push on production with broken assets.

Hi,

first: thank you very much for this composer plugin!

I have a suggestion for pre-compiled adapter: It would be helpful to take only a part e.g. the dist or asset folder from the zip file and place it in the target folder.

Often you attach a compiled zip to the Github release with all the files but just need one folder with the assets.

Description of the bug

The recent merge commit 793bc8e leads to [410] status when downloading the assets. The build ends up stuck without moving further.

Looks like the merge commit stated above left out ! right here

Please compare with this commit c6af642 on the difference.

Reproduction instructions

1. Setup a repository with a dependency on version constraint.
2. Execute the command composer compile-assets -vvv to view the log on [401] during downloading assets for the dependency.

Expected behavior

Assets should be installed with default configuration or use preprocessed assets when a valid API response is not obtained.

Environment info

• Package version : master

Relevant log output

No response

Additional context

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

Is your feature request related to a problem? Please describe.
First of all, thanks for this plugin. It really helps with the JS in Composer problem!

One of the great things about this plugin, is that it automatically does a lot automatically without any developer needing to know the ins-and-outs. However, by default it is hard to see what is happening - which is somethimes frustrating when a package is installing/building slow or if something is failing.

For example, this is how a project I'm working in looks with this plugin:

  - Installing drupal/administration_language_negotiation (1.11.0): Extracting archive
  - Installing drupal/admin_toolbar (3.0.2): Extracting archive
  - Applying patches for drupal/core
    https://www.drupal.org/files/issues/2018-07-13/1797438-145.patch (HTML5 validation is preventing form submit and not fully accessible)
    https://www.drupal.org/files/issues/2018-10-17/core-typed_config_handle_missing_config-2925297-7.patch (Fatal error on config form with translation enabled when config is missing)
    https://git.drupalcode.org/project/drupal/-/commit/ef2f0e3109e30da63341cf60779ff845b24e2e1a.patch (#3222107 - jQuery UI library order is incorrect when a large number of javascript files is loaded between two jQuery UI libraries)
    https://www.drupal.org/files/issues/2020-06-10/locale-config-langcodes.patch (#3150540 - Configuration langcode is forced to site default language)
  - Applying patches for drupal/webform
    https://www.drupal.org/files/issues/2021-11-09/70.patch (#3240249 - Aria-required on fieldset trigger accessibility fails.)
    https://git.drupalcode.org/project/webform/-/merge_requests/96.patch (#3252029 - Aria-required on fieldset trigger accessibility fails. (part 2))
    https://git.drupalcode.org/project/webform/-/commit/0056d54e445907caabfef6157c78cfd9115a40a7.patch (#3246947 - Only load jQuery UI Datepicker when needed)
Package swiftmailer/swiftmailer is abandoned, you should avoid using it. Use symfony/mailer instead.
Package twig/extensions is abandoned, you should avoid using it. No replacement was suggested.
Package webmozart/path-util is abandoned, you should avoid using it. Use symfony/filesystem instead.
Generating autoload files
101 packages you are using are looking for funding.
Use the `composer fund` command to find out more!
                            
            Inpsyde         
                            
    Composer Assets Compiler
    
    starting...
    
    
    done.
    
Scaffolding files for drupal/core:
  - Copy [project-root]/.editorconfig from assets/scaffold/files/editorconfig
  - Copy [project-root]/.gitattributes from assets/scaffold/files/gitattributes
  - Copy [web-root]/.csslintrc from assets/scaffold/files/csslintrc
  - Copy [web-root]/.eslintignore from assets/scaffold/files/eslintignore
  - Skip [web-root]/.eslintrc.json: overridden in dvg/io_dvg
  - Copy [web-root]/.ht.router.php from assets/scaffold/files/ht.router.php
  - Copy [web-root]/.htaccess from assets/scaffold/files/htaccess
  - Copy [web-root]/example.gitignore from assets/scaffold/files/example.gitignore
  - Copy [web-root]/index.php from assets/scaffold/files/index.php
  - Copy [web-root]/INSTALL.txt from assets/scaffold/files/drupal.INSTALL.txt
  - Copy [web-root]/README.md from assets/scaffold/files/drupal.README.md
  - Copy [web-root]/robots.txt from assets/scaffold/files/robots.txt
  - Copy [web-root]/update.php from assets/scaffold/files/update.php

The Composer Assets Compiler part really looks off, compared to other plugins (composer patches & drupal-scaffold).

And if something fails, the 'done' part just changes to 'failed.' - which is not very helpful.

Describe the solution you'd like
I think it would be totally possible to improve the output a bit, so it looks more consistent with other Composer plugins, and gives a bit more output without being too verbose.

I believe that it is possible for multiple installs/builds to occur concurrently, right? In that case, I can imagine that something like this would be great:

Compiling assets of composer packages using npm:
  - Starting dependency installation of bartlangelaan/package1...
  - Starting dependency installation of bartlangelaan/package2...
  - The bartlangelaan/package3 are already compiled
  - Dependencies of bartlangelaan/package2 have completed installing. Starting assets compilation...
  - Assets were succesfully compiled for bartlangelaan/package2
  - Dependencies of bartlangelaan/package1 have completed installing. Starting assets compilation...
  - Error. The compilation of bartlangelaan/package1 did not succeed.

The command was run in /home/bart/git/project/vendor/bartlangelaan/package1
The command executed was: npm run build
The command gave the following output:
[full npm output]

Output like this is not too verbose, because it just generates 3 lines per package that is being compiled, or 1 line for packages that were already compiled. At the same time, it gives a great impression of what is happening (package manager used, actions currently running, error output). It also looks more consistent with other plugins, without the Inpsyde banner.

Describe alternatives you've considered

I did think about always enabling verbose mode, which gives more output. However, I just want this plugin to show more output, I don't need full verbosity output whenever an npm build is failing.