Skip to content

updating stimulus-bridge plugin to work with proposed new loader #888

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Jan 27, 2021

Conversation

weaverryan
Copy link
Member

@weaverryan weaverryan commented Jan 22, 2021

Partner to symfony/stimulus-bridge#14

  • Wait for partner PR to be merged

lib/features.js Outdated
@@ -152,7 +152,7 @@ const features = {
method: 'enableStimulusBridge()',
packages: [
{ name: '@symfony/stimulus-bridge' },
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

shouldn't we enforce the version here too (even more than for stimulus) ?

lib/features.js Outdated
@@ -152,7 +152,7 @@ const features = {
method: 'enableStimulusBridge()',
packages: [
{ name: '@symfony/stimulus-bridge' },
{ name: 'stimulus' }
{ name: 'stimulus', enforce_version: true }
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the commit message talks about bumping stimulus version, but that's not what you bumped

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yup - this was a mistake - it should be on the other one - thanks for catching!

tgalopin added a commit to symfony/stimulus-bridge that referenced this pull request Jan 22, 2021
…on (weaverryan)

This PR was squashed before being merged into the main branch.

Discussion
----------

Replacing virtual-modules with a loader for controller.json

Hi!

The motivation behind this was a few things:

1) the wepback-virtual-modules plugin emits a worrying warning in Webpack 5 and, in general, doesn't seem to be super-actively developed.
2) sokra says that a loader is the correct solution: webpack/webpack#11074 (comment)
3) Since loaders are native/normal, this works well with `watch` mode and should work just fine with Webpack 5 persistent build caching.

This also includes a tricky NormalModuleReplacementPlugin() so that we can continue to handling the parsing of the user's controller.json inside this library (instead of putting the import + loader code in their app).

This will require a partner PR in webpack-encore (symfony/webpack-encore#888). The only line users will need to change in their app is to remove `import '@symfony/autoimport';` from their `assets/bootstrap.js` file.

Cheers!

Commits
-------

fb5aaf7 Replacing virtual-modules with a loader for controller.json
weaverryan added a commit that referenced this pull request Jan 23, 2021
…pack 5 persistent caching (weaverryan)

This PR was squashed before being merged into the main branch.

Discussion
----------

[Webpack 5] Adding new enableBuildCache() method for Webpack 5 persistent caching

Hi!

This is a very simple feature, but it can also easily be improperly used. It is part of #880. See some comments about it from @Lyrkan from #645:

> Things can easily go wrong with persistent caching... even only enabling it for the config file could lead to some issues if not done properly (for instance if the config use values coming from environment variables, which is far from an edge case imo: https://github.com/webpack/changelog-v5/blob/master/guides/persistent-caching.md#version).

The trick, for us, is to:

A) Make sure we are doing everything as correctly as we can. For example, I assume that WE don't need to include `.babelrc` or `postcss.config.js`, but I actually don't know that for sure. Should we also potentially be adding Encore itself to the build dependencies?

B) Good communication in the documentation above the method and in the (eventual) recipe where we include this in the user's webpack.config.js file

## TODO

* [ ] 1) Test in a real project to see if we're missing anything (also play with what the valid keys are under `buildDependencies` - other than `config`, this is not documented anywhere).
* [x] ~~2) Check into Stimulus: I'm curious if `controllers.json` will need to be added to the build dependencies. I'm also curious if the UX vendor libraries will need to be in the build dependencies, as these do not follow the normal versioning (i.e. their directories in `node_modules/` can change without a change to `yarn.lock` or `package.json`)~~ should be solved by linked changes in #888

Cheers!

Commits
-------

a592c82 lint
9f117a4 fixing test
7a39654 Adding new enableBuildCache() method for Webpack 5 persistent caching
@weaverryan weaverryan force-pushed the stimulus-bridge-loader branch from 57ac055 to b0bbb5a Compare January 23, 2021 15:38
@weaverryan weaverryan mentioned this pull request Jan 23, 2021
10 tasks
@weaverryan weaverryan force-pushed the stimulus-bridge-loader branch 4 times, most recently from a33cfc4 to 35b11b3 Compare January 27, 2021 18:40
@weaverryan weaverryan force-pushed the stimulus-bridge-loader branch from 35b11b3 to 5640760 Compare January 27, 2021 18:44
@weaverryan weaverryan merged commit 42aab44 into symfony:main Jan 27, 2021
@weaverryan weaverryan deleted the stimulus-bridge-loader branch February 1, 2021 15:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants