Awesome! As far as I understand this would solve the hardcoding issue in config/webpack/custom.js and config/webpacker.yml, reported in #8028 and #8006.

As far as I understand this would solve the hardcoding issue in config/webpack/custom.js and config/webpacker.yml, reported in #8028 and #8006.

@andreslucena It might help resolving #8028 but there are also other pending changes at #7942 which are also required. I won't guarantee that but I think it might help.

Regarding #8006, the webpacker install command is still needed to run but yes, this sure gets rid of the statically configured paths.

Amazing job @ahukkanen!! 😍
Is this PR ready to be reviewed or there's any pending thing to be done?

@leio10 On my part it's ready to be reviewed but I would like other people to also confirm if this is the correct way to solve the problem.

I'm also taking a look. Great job @ahukkanen, I wanted to avoid hacking on Webpacker classes but might be the path to follow

After reviewing it it solves the problem of the webpacker.yml in a nice way and it's definitely an improvement on my proposed solution. I'm updating #7942 with the last version of bulletin board to have a version without sprockets.

On the regards with the issue with package.json Decidim dependencies included in the Rails app I haven't been able to think in a better approach, so let's wait to @leio10 feedback. Maybe from this PR, Webpacker could be moved again to Decidim gem, but I'm not sure and it'd need some experimentation to validate.

@ferblape IMO the Decidim NPM dependencies should be managed as a Decidim's own NPM package.

Then instances could just do this in their package.json:

{
  "dependencies": {
    "@decidim/essentials": "^0.25.0"
  }
}

And in the Decidim upgrade task, you could just update the version number from the package.json.

Will that npm package just contain the package.json of Decidim?

@ferblape At first: yes. Later possibly something else too (once the related discussion is resolved).

Hi @ferblape @ahukkanen, let me try to summarize what I understood until now, to see if I have a clear idea of the situation:

1. This PR is an improvement over what we have in main, as it removes the need hardcode the paths of the app in the webpacker YAML. But it doesn't address the problem of the applications: Decidim will override their package.json file (if it exists) and will require to install all the Decidim JS dependencies in the application package.json to be able to compile the assets.
2. @ahukkanen proposal is to undo the current approach and release an NPM package for each released version, that should be automated somehow. This would simplify the use of Decidim in the applications, as explained here. I also understand that this approach would also allow applications to override JS and CSS within the application. The only "problem" commented in the referred discussion is that this approach will force apps to use Webpacker, but that's already happening, right?

Please let me know if I'm missing something here.

Regarding NPM packages, I don't see any benefit on having just one big package. I think we could use the same approach that we are using with the ruby gems: one independent package per module and a set of well defined dependencies between them. I know that it's more work but that could be automated. In fact, that was the idea from the beginning for the Decidim project, to have small parts as less coupled as possible, so I don't see a reason to not do that in the JS part.

That say, and again if I'm not missing anything, I'd say that IMHO the best approach would be to publish one NPM package for each module and request to apps maintainers to add webpacker with a package.json that included the needed dependencies.

What do you think?

@leio10

1. Yes. you are correct on this. This is an improvement to the current situation but does not solve the problem with package.json.
2. This is something that I actually thought a bit differently. I thought only to release the Decidim's own NPM dependencies in a package so that we could simplify the NPM dependency management without having to overwrite package.json in the application. This way, application developers could just add a single line in the application's package.json and get webpacker working correctly within the instance.

I'm still not sure whether all Decidim gems should be released as their own NPM packages. It would be still possible to do overrides that way too as @leio10 mentioned, but we would have to give priority for the registered additional_paths over the node_modules folder. Right now it is the other way around (node_modules will get priority making it impossible to do overrides).

In case all modules had their own NPM package, it probably would make Decidim upgrades a bit more difficult, having to manage all that in a single place. And I'm a bit worried what happens if the gems are running on 0.25.x and the application developer decides to run npm update (which would pull e.g. 0.26.x versions of the assets)... That might lead to conflicts breaking some front-end functionality.

@leio10 do you want me to help you to create a package.json that contains all the dependencies? In fact I can't create it an publish on Decidim npm account, but I could prepare the generators to use it in a new PR?

@ferblape I think right now you can already do that by pulling the Decidim's package.json from GitHub. Just run this at the project root:

npm i --save decidim/decidim#develop

Before that is released to NPM, I would suggest to move some of the dependencies to devDependencies which are not particularly required within the instance. Such packages include:

• yaml-jest
• jest
• jest-localstorage-mock
• babel-jest
• babel-plugin-__coverage__
• babel-preset-airbnb (not sure)

Maybe the released package should be named something like @decidim/essentials so that if each gem would later release their own packages, it would leave those names available.

@ferblape @leio10 See #8094 for the package.json solution.

I could be improved but that should do the trick for the time being.

ok, @ahukkanen @ferblape my plan is to review and merge this PR to close open issues, and then I'll address the package.json issue. Ok?

@leio10 OK for me.

Please also merge @ferblape's #7942, that one is important.

@ahukkanen I'm following the webpacker component migration guide and it was not updated with this PR. Could you add these changes to the guide? Thanks!

/cc @ferblape

@leio10 See #8180

/cc @ferblape